Thanks Stephen, I like the patch. Without it: 1. Having to remember to enable TMPFS_FS_SECURITY seems silly. If I want selinux, obviously I want this. 2. The xattr handlers end up being silly. To clarify: the security implication of including the fs/xattr.c:setxattr part of the patch is that for a filesystem which does not support setxattr, the security_inode_setsecurity is unconditionally called for "security.*" values? So that a module which unconditinally acted upon the values sent to security_inode_setsecurity() could be tricked? I would agree that it is best to make it well known that this should be controlled through policy on filesystem types. As an alternative, what about calling security_inode_setxattr() before the setsecurity() anyway, and making it clear that security_inode_setxattr() should be used as an authorization hook, and security_inode_post_setxattr() should be used for any actions? thanks, -serge Quoting Stephen Smalley (sds@private): > On Fri, 2005-07-15 at 11:28 -0400, Stephen Smalley wrote: > > This is a request for comments on the below patch that modifies the VFS > > setxattr, getxattr, and listxattr code to fall back to the security > > module for security xattrs if the filesystem does not support xattrs > > natively. This allows security modules to export the incore inode > > security label information to userspace even if the filesystem does not > > provide xattr storage, and eliminates the need to individually patch > > various pseudo filesystem types to provide such access (note that this > > patch removes the existing xattr code from devpts and tmpfs as it is > > then no longer needed). This patch was written by a colleague who > > prefers to remain anonymous. > > > > An optional variant would be to only provide such fallbacks for getxattr > > (and possibly listxattr, so that any programs that first query for the > > list of attributes will see the security xattr name), but not setxattr. > > That seems safer (although policy can always prevent setxattr on > > particular filesystem types), but would require retaining the special > > handlers in devpts and tmpfs, as they need to support setxattr, and > > patching any other pseudo filesystems that need to support setxattr. > > Not sure ultimately what will be the right way to handle labeling of > > filesystems like sysfs, i.e. exporting setxattr and letting early > > userspace label it or having the kernel internally assign labels based > > on some mapping. > > Hi, > > I haven't seen any discussion of the optional variant described above, > which I actually expected to provoke the most discussion. Any strong > opinions on it? > > -- > Stephen Smalley > National Security Agency > >
This archive was generated by hypermail 2.1.3 : Mon Jul 25 2005 - 08:58:35 PDT