oss-sec mailing list archives
Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks
From: Casey Schaufler <casey () schaufler-ca com>
Date: Wed, 21 Jan 2015 08:15:12 -0800
On 1/21/2015 6:03 AM, Stephen Smalley wrote:
On 01/20/2015 06:17 PM, James Morris wrote:On Sat, 17 Jan 2015, Ben Hutchings wrote:chown() and write() should clear all privilege attributes on a file - setuid, setgid, setcap and any other extended privilege attributes. However, any attributes beyond setuid and setgid are managed by the LSM and not directly by the filesystem, so they cannot be set along with the other attributes. Currently we call security_inode_killpriv() in notify_change(), but in case of a chown() this is too early - we have not called inode_change_ok() or made any filesystem-specific permission/sanity checks. Add a new function setattr_killpriv() which calls security_inode_killpriv() if necessary, and change the setattr() implementation to call this in each filesystem that supports xattrs. This assumes that extended privilege attributes are always stored in xattrs.It'd be useful to get some input from LSM module maintainers on this. e.g. doesn't SELinux already handle this via policy directives?There have been a couple postings of a similar patch set [1] by Jan Kara, although I don't believe that series addressed chown(). If I am reading the patches correctly, they (correctly) don't affect SELinux or Smack labels; they are just calling the existing security_inode_killpriv() hook, which is only implemented for the capability module to remove the security.capability xattr.
The description of the change should say that. I can easily imagine an enthusiastic test developer reading the existing description and filing bugs because SELinux, Smack and whatever other xattr based systems might be around don't clear their attributes. If the intent wasn't clear to the first person to use xattrs for security purposes, I shouldn't expect the new and inexperienced to see it. My position softens. Document it correctly, and I'm fine with it.
[1] http://marc.info/?l=linux-security-module&m=141890696325054&w=2
Current thread:
- [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Ben Hutchings (Jan 17)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks James Morris (Jan 20)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Casey Schaufler (Jan 20)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Stephen Smalley (Jan 21)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Casey Schaufler (Jan 21)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Solar Designer (Jan 21)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Ben Hutchings (Jan 21)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks Josh Boyer (Feb 16)
- Re: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks James Morris (Jan 20)