Re: pathnames

sdsat_private

SELinux stores a persistent labeling table in each file system that
specifies the security label for every inode in that file system.
For efficient storage, SELinux assigns an integer persistent
security identifier (PSID) to each distinct label used by an
inode and partitions the persistent labeling table into
a mapping from inodes to PSIDs and a mapping from PSIDs to labels.
The first mapping is implemented using a spare field in the
on-disk ext2 inode in the original SELinux prototype, but
it is implemented using a regular file in the LSM-based prototype
since we do not have ext2-specific hooks.  The second mapping
is implementing using regular files in both prototypes.

Since the labels are stored in each file system, they aren't
dependent on the system-wide namespace (i.e. mount hierarchy)
or on any system-wide labeling files (like /etc/passwd for uids
or the DTE configuration for DTE type assignment).  Since the
persistent labeling table is inode-based, it isn't affected by renames
or multiple hard links.

When SELinux is installed, a utility program (setfiles) sets the label 
on each existing file in accordance with a configuration file
(file_contexts) that maps pathname regular expressions to labels.
The utility initializes the persistent labeling table for existing
files in each file system.  After this initialization, this
configuration file is not used again unless one wants to
restore the entire file system to its initial state.

The security policy configuration is separate from the labeling
configuration and only deals with attributes, not pathnames.  When new
files are created during runtime, a label is computed in accordance with
attribute-based rules in the policy configuration, e.g. when a process in
domain D creates a regular file in a directory of type T1, use type T2
for the new file.  That label is then assigned to the inode in the
persistent labeling table.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

On Fri, 29 Jun 2001, Serge E. Hallyn wrote:

> On implicit type attributes based on pathnames at runtime:
> 
> It appears to me that, given a dentry and vfsmnt, we need to be able
> to find a real pathname for a file  (disregarding hard links as
> always, which i'm sure we all have our own ways of dealing with :).
> 
> Also, from what i understand about selinux' way of doing things, they
> also will need to be able to see through bind mounts, multiple mounts
> and private namespaces, in order to ensure that, if /a/b/c is assigned
> a label, but nothing below that, then /a/b/c/d/e/f will be assigned the
> same label, even if /a/b/c/d/e has been mounted --bind to /d/e/a.  For
> instance.  But maybe I misunderstood, and every single inode on the system
> is actually in the backing file.
> 
> The way I solve this is to attach two pointers to struct vfsmount, one
> to the real vfsmount parent, and one to the real dentry parent.  Of
> course, I allow a policy to specify that given devices must be mounted
> at certain pathnames (that would be done in a lsm module, I only mention
> it to clarify that the resulting pathnames are not only unique, but
> also not predictable :).  But the two pointers we would definately need.
> A modified d_path which follows those pointers could be part of lsm, or
> part of an lsm module, so long as the necessary info (full dentry and
> vfsmount trees) is available in modules.
> 
> My understanding of per-process namespaces is that this solution would
> work for them as well.
> 
> Of course, if we ask to modify the vfsmount structure, we may be
> asking too much.  But if we can't do that, then perhaps we *should*
> remove the other pathname-based label assignment functions, in order
> to give the rest of lsm a better chance.  Naturally, that is not my
> preference.
> 
> Comments?
> 
> -serge

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module