Re: NFSv4

From: Jesse Pollard (
Date: Sat Aug 04 2001 - 14:38:57 PDT

  • Next message: Crispin Cowan: "Re: NFSv4"

    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
       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
    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
    Jesse I Pollard, II
    Any opinions expressed are solely my own.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 15:01:35 PDT