[lkml]   [2009]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.
    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 <>
    > 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. 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. I'd like to hear what Greg thinks
    about that.


     \ /
      Last update: 2009-07-09 16:53    [W:0.021 / U:50.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site