Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

On Wed, 2003-04-16 at 18:02, richard offer wrote:
> If you attach a capability attribibute to a file under the capability
> module, what happens when you use SELinux ? Under your scheme, you'd remove
> the capability and write a combined attribute that included SELinux and and
> if needed the capability. 

Yes.  You have to initially label the filesystem in order to use
SELinux, as you would with any MAC scheme, and incorporating additional
state into that labeling procedure wouldn't be difficult.  It isn't
clear that you actually need the additional state; you can assign
privileges via TE rather than using capabilities if you want
fine-grained decomposition of root.

However, point taken - if the existing Linux capability model (in the
mainline kernel) was already using xattr and had an attribute name
reserved, I don't think we would have suggested re-using that attribute
name (or its handler) for all security modules.  I view this as a
special case, as the capability model was already in mainline and is
expected to exist by certain applications, so colliding with it could
pose a problem for many security modules.  For other security modules,
or at the very least, the class of security modules implementing a MAC
scheme, I would still suggest a single attribute name and handler.  

> Under my scheme, the capability attribute would be left alone, SELinux
> would add its own, and then as its the primary module would decide whether
> to use the existing capability attribute or its own "combined" attribute.
> The important thing is that if you ever decide to reboot a pure capability
> system that you don't have to refigure all your attributes (although you
> could/should).

True.  As above, I view this as a special case for the capability model
because it has been part of the mainline.  If I am switching between
different MAC schemes, I need to do a thorough relabeling of the
filesystem, and that relabeling is a delicate operation as one MAC
scheme may permit data mixing that is prohibited by another, leading to
a violation of confidentiality or integrity requirements of the other
MAC scheme.  Also, note that if you switch from a MAC scheme to a
capability-only scheme, switching back is a very delicate operation if
you want to verify a secure state.

> Extended attributes are still relatively rare that people forget to record
> them when replacing a file (I do that all the time under Trusted Irix),
> under your scheme they would have to record every attribute on the system
> before loading a module if they every wanted to return to its prior state.
> If you forgot to do it just once the consequences could be nasty.

Since you have to initially relabel the filesystem to switch to a
different MAC scheme, it isn't unreasonable to have that labeling step
also make a backup of any existing attribute values prior to changing
them.

> I can see your reasons for the single attribute (known quantity for
> production systems), but think its better at this stage to experiment with
> multiple attributes and see how people use them before forcing everyone to
> a single standard. It allows small steps rather than force everyone to make
> a single large one.

Per-module attribute names create no incentive for the security module
writers to provide a consistent API and guarantees a forked userland. 

-- 
Stephen Smalley <[e-mail]>
National Security Agency