Quoting Stephen Smalley (sds@private): > On Mon, 2006-01-02 at 14:06 -0500, schaufler-ca.com - Casey Schaufler > wrote: > > Casey takes a deep breath... > > > > The filename is not an attribute of the file. > > The pathname components are data contained > > in directory entries. The association of path name > > to inode number is one way. There is no association > > of path name from file. Really. This is the thing > > that make audit hard. > > > > Yes, I know "It's obvious". It's just not true. > > The world is ending because I agree with Casey on this one... > The filename is not an attribute of the file, and we do not want this > type of filtering on directory reads. Use the permissions on the > directory itself to control who can see the names it contains. It is > the data container for the filenames. > > Use polyinstantiation aka Multi-Level Directories aka moldy directories > for shared directories like /tmp. Looking at the second "application note" for 5.3.4.1 of PP_MLOSPP_MR (from http://niap.nist.gov/cc-scheme/pp/PP_MLOSPP-MR_V1.22.html), it says: "The MAC policy covers all subjects and all objects. The list of objects must include object attributes that are themselves objects (such as filenames) because they can be manipulated by a user." So it sounds like to meet this profile, we'd have to either have separate controls on the filename, or extend a file's read/write access rights to any dentry pointing to the inode. Of course I'd resigned myself long ago to not being able to meet this application note :) Particularly due to the aforementioned hard-to- handle information leak on touch(/var/somefilename). So I'm not arguing with the decision to abort this patch. -serge
This archive was generated by hypermail 2.1.3 : Thu Jan 05 2006 - 06:57:20 PST