linux-kernel - Re: [PATCH 7/8] SELinux: Create a common helper to determine an inode label

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5582E7FE.5090904@tycho.nsa.gov>
Date:	Thu, 18 Jun 2015 11:47:10 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	David Howells <dhowells@...hat.com>
CC:	viro@...iv.linux.org.uk, miklos@...redi.hu,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	SELinux <selinux@...ho.nsa.gov>, Paul Moore <paul@...l-moore.com>
Subject: Re: [PATCH 7/8] SELinux: Create a common helper to determine an inode
 label

On 06/18/2015 11:32 AM, David Howells wrote:
> Stephen Smalley <sds@...ho.nsa.gov> wrote:
> 
>>> Fair point.  What does SBLABEL_MNT mean precisely?  It seems to indicate one
>>> of an odd mix of behaviours.  I presume it means that we *have* to calculate a
>>> label and can't get one from the underlying fs if it is not set.
>>
>> It means the filesystem supports per-file labeling and you can use
>> setxattr(..."security.selinux") and setfscreatecon() for files on it.
>> You can see whether it is set on a filesystem by looking for the
>> seclabel option in cat /proc/mounts.  If it is not set, then we ignore
>> tsec->create_sid.  It is arguable as to whether it is correct to always
>> call security_transition_sid() there either, but that's another topic.
> 
> Okay, so how about the attached?
> 
> David
> ---
> static int selinux_determine_inode_label(const struct inode *dir,
> 					 const struct qstr *name,
> 					 const char *caller,
> 					 u16 tclass,
> 					 u32 *_new_isid)
> {
> 	const struct superblock_security_struct *sbsec = dir->i_sb->s_security;
> 	const struct inode_security_struct *dsec = dir->i_security;
> 	const struct task_security_struct *tsec = current_security();
> 
> 	if ((sbsec->flags & SE_SBINITIALIZED) &&
> 	    (sbsec->behavior == SECURITY_FS_USE_MNTPOINT)) {
> 		*_new_isid = sbsec->mntpoint_sid;
> 	} else if ((sbsec->flags & SBLABEL_MNT) &&
> 		   tsec->create_sid) {
> 		*_new_isid = tsec->create_sid;
> 	} else {
> 		return security_transition_sid(tsec->sid, dsec->sid, tclass,
> 					       name, _new_isid);
> 	}
> 
> 	return 0;
> }

That looks good to me.  In fact, I'd take a patch that defines that
function and rewrites may_create(), inode_init_security(), and
dentry_init_security() to use it even before (or independent of) the
union support patches.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/