Messages in this thread | | | Date | Thu, 09 Jul 2009 07:49:07 -0700 | From | Casey Schaufler <> | Subject | Re: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks. |
| |
David P. Quigley wrote: > On Wed, 2009-07-08 at 18:44 -0700, Casey Schaufler wrote: > >> David P. Quigley wrote: >> >>> This patch adds a setxattr handler to the file, directory, and symlink >>> inode_operations structures for sysfs. This handler uses two new LSM hooks. The >>> first hook takes the xattr name and value and turns the context into a secid. >>> This is embedded into the sysfs_dirent structure so it remains persistent even >>> if the inode structures are evicted from the cache. The second hook allows for >>> the secid to be taken from the sysfs_dirent and be pushed into the inode >>> structure as the actual secid for the inode. >>> >>> >> Nacked-by: Casey Schaufler <casey@schaufler-ca.com> >> >> I'm all for sysfs supporting xattrs. >> >> I am completely opposed to secids as file system metadata. >> >> What do you get when you do an ls -Z? >> >> An LSM must not be beholden to exposing transient internal >> representations of security data to userspace, which is what >> you're doing here. An LSM gets to decide what the security >> information it maintains looks like by defining a security blob. >> >> If you want this in, implement xattrs in sysfs for real. Smack >> depends on the existing, published, and supported xattr interfaces >> for dealing with getting and setting the values. Not secids. >> Smack maintains secids because labeled networking and audit require >> them, and they got there first. >> >> >> > > So are you proposing that we embed a variable length string in the > sysfs_dirent structure because that sounds completely silly.
No, I'm not proposing that because it sounds silly, I'm proposing it because that's the way xattrs work on Linux.
> It seems > completely reasonable here to take the blob coming in and have the LSM > turn it into a handle that is efficiently referenced by the > sysfs_dirent. The problem here is that sysfs entries have no backing > store at all which means everything we do will have to be added to > sysfs_dirent. I'm pretty sure we don't want to be doing lifecycle > management on strings inside this structure considering the only other > string I see is marked const. If you have a better way of doing this I'm > interested in hearing it but it doesn't seem reasonable to be storing > the xattr itself in the sysfs_dirent.
Smack depends on the xattr interfaces to inspect and manipulate labels on file system objects. Now you have a file system that "supports" xattrs, but not the xattr interfaces. What if I want to change the label on a sysfs entry? Or even read it? I can't with your scheme.
You are proposing a one-off hack to solve a particular problem. It introduces issues of its own. I don't care that it is clever and compact. It's not right.
> I'd like to hear what Greg thinks > about that. > > Dave > > >
| |