Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley <sds@epoch.ncsc.mil>]

On Wed, 2003-04-23 at 14:54, Andreas Dilger wrote:
> Well, with the exception of backup/restore (which will just treat this
> EA data as opaque and doesn't really care whether the names are fixed
> or not), the tools DO need to understand each individual module
> or policy in order to make any sense of the data.  Otherwise, all you
> can do is print out some binary blob which is no use to anyone.

You are assuming that the ondisk representation is a binary blob.  If
you store a string representation as your security label, then your
userspace tools can operate on it cleanly without caring what it
actually means.  SELinux includes patched versions of many of the user
utilities that can get or set file security labels, and it doesn't
matter whether the security label consists of a MLS range or a TE domain
or a RBAC role or any combination of them.

For MAC, you want to preserve meaningful security information on the
filesystem partition itself (and in any backups), not some arbitrary
integer that might be remapped at any time to a completely different
meaning or that might mean something quite different if you mount the
disk on some other system.  A human-readable string representation is
preferable here.

> So, either the tools look for "system.security", and then have to
> understand an internal magic for each module to know what to do with
> the data, or it looks for "system.<modulename>" for only module names
> that it actually understands.

Again, if you are using a string representation, then most of your
userland can simply display it or take input from the user and pass it
down without caring about the meaning of the string.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency