On Sat, 04 Aug 2001, Crispin Cowan wrote: >jmjonesat_private wrote: > ... >> I'm not convinced that "special filesystems" are common enough to call them the >> "general case." > >Not yet, but they will be. In the near term, the non-requirement for extended >attributes gives models like SELinux and SubDomain an advantage over more classical >security models like MLS, which require Security Labels[tm] on files. There are many ways to get labels on files. 1. put the label in the inode (requires significant modification to the inode - the label may have a LOT of bits) 2. put a label identifier in the inode (use an unused 32/64 bit field in the inode), then lookup the identifier in a keyed file on the same filesystem. 3. keep a key file containing the label indexed by inode (most generic) the key file must reside on the same media as the filesystem. The advantage of 2 over 3 is that the same identifier may be used on multiple files. The advantage of 3 over the rest is that it can be done on any filesystem that has inode numbers on disk. This even includes the possiblity of using the inode as a key to an identifier, which in turn is a key to the label. #2 could use the identifier to generate a unique key on those file systems that don't have inodes, in effect - creating an inode number. This has the advantage of working on any filesystem that has an unused 32/64 bit field. The only requirement for all of them is that the label database must reside on the same media as the file system. That way the label is available no matter how it is mounted - even multiple mounts should work. It also would appear that it would be possible (not necessarily desirable, or easy) for the LSM to be capable of bypassing the VFS to access the extended features provided by the filesystem - provided the filesystem DID have a hook in the file ops to access these features. The LSM may be able to use the "lsm_inode_permission" as a way to evaluate the extended feature. It seems more likely that such an ability would be used to evaluate the capability, debug the feature, test... before such a feature is added to the VFS. -- ------------------------------------------------------------------------- Jesse I Pollard, II Email: jesse@cats-chateau.net Any opinions expressed are solely my own. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 15:01:35 PDT