On Fri, 2005-07-15 at 08:53 -0700, Casey Schaufler wrote: > Wouldn't it be better to just introduce the > required changes to bring the filesystems that > don't support xattrs into the 21st century? > There can't be that many by now, and it's not > as if (as the proposed patch demonstrates) > it would be that much work. I would hope to > see the existing mechanism used as designed > rather than see a special hack put in to > accomodate a special case. There are a number of filesystem types supported by Linux that do not support xattrs natively, and that likely never will (think about both pseudo filesystem types and legacy filesystem types). Yet in a MAC scheme, every inode has to have some security label associated with it (incore, by the MAC security module), and it would be preferable if that security label could be accessed from userspace (at least for getxattr); in fact, some have suggested that this is important for LSPP. Allowing the security module to return that information to userspace if the filesystem doesn't natively support xattrs seems quite logical to me, and is already being done in the tmpfs and devpts cases via special security xattr handlers that we added earlier to them that just redirect to the security module. This patch just avoids the resulting code duplication among all such filesystem types. Note that the patch only falls back to the security framework if the filesystem has _no_ xattr handler at all. Hence, if the filesystem has any xattr handler, then it is still necessary to add a security xattr handler to it. This is only providing fallbacks for filesystems that have no native support for xattrs. > The xattr mechanism works very well, and has > a long history that predates inclusion in Linux. Not sure how Trix or Trusted Solaris address the same issue. Do they only export the xattr API, or do they also have a separate API for getting/setting MAC labels (not just one that is layered on top of the xattr API)? If the former, then how do they allow userspace to unambiguously get the "effective" MAC label of an inode when: - the filesystem doesn't support xattrs (think particularly of pseudo filesystems and legacy filesystems), or - the filesystem supports xattrs but the particular inode lacks an xattr, or - the filesystem supports xattrs but the particular filesystem is untrusted (removable media, remote filesystem, etc) and the kernel is mapping all inodes in it to a particular security label specified at mount time. Note that this patch doesn't address the latter two issues, which are also a concern. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 18 2005 - 05:39:05 PDT