[fmac-discuss] FMAC support needed in file system?

[Stephen Smalley]

On Sun, 2008-07-27 at 13:50 -0600, Mark Shellenbaum wrote:
> I would like to start a discussion on what is needed to
> be stored in the file system (ZFS) to support FMAC.
> It looks like you need a security context and PSID?

In Linux, we now store the security context as an extended attribute of
the inode.  If the inode has sufficient space, then the extended
attributes can be stored inline; if not, they are stored out of line in
separate data blocks.

PSIDs were an artifact of the original SELinux implementation; they
aren't used presently.  The idea there was that we would only store an
integer PSID in the on-disk inode and use it as an index into a security
context mapping stored in the filesystem.   They went away when we
migrated to using native Linux extended attributes.

> I have a number of questions about this.
> 
> - The security context is a string.  Is the string variable in size?
>    Is there a max/min length?

The string is variable in size.  The core logic imposes no limits on its
size but the syscall interface does impose an upper limit; at present
this is defined as FMAC_MAX_CONTEXT_LEN in fmac/fmac.h.  That is
currently defined as 4K, similar to the Linux interface limitation.  In
practice, the context strings are usually much smaller, less than 64
bytes, but can grow larger if you are using MLS and have a large set of
categories.

> - Is the security context just opaque data to the file system?

Yes - opaque to the filesystem but interpreted by FMAC and used by it
for access control decisions.

> - Does every file/dir have a security context?  Will the same security
>    context be used for multiple files or is it unique to every file
>    system object?

Each file/dir can potentially have its own distinct context, but often
an entire directory tree may have a single context.  In Linux, sharing
of extended attribute data blocks is possible when they are stored out
of line from the inode.

> - The PSID appears to be just a simple number, that only the kernel is
>    concerned with.  Is this private to the file system, or does the FMAC
>    code need to be able to retrieve it.

We don't use them anymore, but in the original SELinux implementation,
they were private to the filesystem.

> - Will a user application be setting the context or will it only be set
>    by the kernel?

Both.  A userspace process can specify the context to use when creating
new files (setfscreatecon) or can relabel an existing file (setfilecon)
if authorized by policy, and the kernel will initially set the security
context of new files, using a policy-provided default computed from the
creating process' context and the parent directory context if the
application did not specify any context.

> - What OpenSolaris privileges are required for setting the context.

FMAC will apply its own set of permission checks to control setting of
the context.   There may be a DAC check applied as well that might
mirror the existing DAC check for chmod().

> - Would it be desirable to create the context at the time a file/dir is
>    created?

Yes, that's required - objects need to be labeled before they can first
be accessed by userspace.

A few other items that merit discussion:
- The userland API for getting/setting the in-core security context of a
file/dir needs to be independent of storage mechanism (i.e. userland
shouldn't need to know whether they are backed by extended attributes or
by some persistent label mapping or purely in-memory constructs for
pseudo filesystems, etc).  In modern SELinux, we have the getfilecon and
setfilecon APIs and associated l* (symlink) and f* (file descriptor)
variants; in original SELinux, we had extended versions of the stat
calls that also included the context information.

- Internally, the vnode operations interface used to get/set the file
contexts from the kernel code (e.g. from FMAC) needs to likewise be
independent of the storage mechanism.  In looking around a bit at
Solaris internals, it seems like we could use the getattr/setattr vnode
ops using the xvattr structure, or we could introduce dedicated
getseclabel / setseclabel vnode ops modeled after the getsecattr /
setsecattr ops that exist for ACLs.

- We need to populate the incore vnode secid before any other thread can
access the vnode on the lookup path.

- We want new files to be labeled "atomically" at creation time.  In
Linux, the inode creation and setting of the extended attribute happen
within the same ext3 transaction.

- Given the differences between Linux extended attributes and Solaris
EAs, if we use Solaris EAs for storage of file contexts, then we'll need
to address certain issues, such as how to protect the EAs from direct
manipulation as files and how to atomically get and set their values.

I have a patch that adds a secid to the vnode, hooks the lookup path to
initialize it (just to a default value at present, waiting on resolution
of some of these issues before I start having it fetch a value from the
filesystem), and exports it to userspace via getfilecon calls.

-- 
Stephen Smalley
National Security Agency