| 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
| ||
|
Message-ID: <4A560363.6050304@schaufler-ca.com> Date: Thu, 09 Jul 2009 07:49:07 -0700 From: Casey Schaufler <casey@...aufler-ca.com> To: "David P. Quigley" <dpquigl@...ho.nsa.gov> CC: jmorris@...ei.org, gregkh@...e.de, sds@...ho.nsa.gov, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org 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@...aufler-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 > > > -- 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/
Powered by blists - more mailing lists