Re: in defense of SELinux

I'm not an SELinux fan, but since Rob just awarded me an honorary Masters
in information security (because I actually know how to write SELinux
policies), let me chime in for just a moment.

Rob: SELinux is *awful* for the classified document problem. Given that
Linux has never and *will* never receive any interesting level of security
certification, we will have a very long wait for you to validate your
assertion. I do agree that SELinux and the older linux controls can have
weird interactions. SELinux really isn't about restricting delegation. It's
about restricting authority generally in a finer-grain way than the classic
UNIX permissions system.

Alan: In one important way, SELinux is *excellent* at dealing with the
credential sharing issue. The "sweet spot" for SELinux policies is in
protecting so-called "daemons". When somebody breaks into those services,
you can twist your head and take the view that this is a form of credential
hijacking. Services tend to have stable behavioral expectations. One thing
SELinux does well is things like "Notwithstanding it's authorities, I
expect that program to behave according to certain patterns in its
interactions at the application boundary, and if it doesn't, something is
wrong." It also provides a reasonable mechanism for implementing access
controls that are based on generalized attribute labels rather than user
identities.  I do agree that it is not useful for protecting authenticated
users from themselves, and therefore not useful for protecting authorized
users from falsely authorized users.

Mark: SELinux authorization is done based on a triple of (user, role, type)
attribute tags, User, here, is the operating user. Role is basically an
application identity. Type is an operation, and of course the authorization
is associated with a particular operation on a particular object or class
of objects. If this stuff had been designed in an ocap framework in the
first place, I think most of this could have been done with ocaps, except
that the user tag doesn't fit the ocap model.

The piece that is *missing* in SELinux, which really should be there, is
that certain actions by an application should cause role transitions. That
is: an application should start in one role, but it should be possible for
the policy to force it to transition to a different role. Usage example:
Once you read this document, you can't talk to the network anymore.

There are four ways in which SELinux *isn't* capturable with an ocap
policy. The first is that it is finer grain. An SELinux application can *
hold* an authority but be unable to wield some of its operations by virtue
of additional SELinux constraints. The second is that SELinux
authentication is contextualized on both user identity and application
identity. The third is that SELinux is robust in the presence of certain
administrative issues. Example: we may intend for (e.g.) the web server to
be able to write a particular log file, but for administrative reasons we
may want to delete the old log file and create a new one in its place. In a
strict ocap model that's doable in theory but inconvenient in practice. In
fact, if you added the required indirection on every file-like object,
you'd find that the statically traced authority of every application had
become effectively infinite. The fourth is that policy is separate from the
application it governs.

The last point is significant. In addition to simplifying a bunch of
practical administration issues, it means that an application which
inadvertently holds too much authority in its initial design can be pruned
back very quickly. Conversely, it means that an application which has
*not* been
granted authority that it requires (e.g. to a log file - a common SELinux
policy error) can be granted that authority. Finally, it means that a great
many applications that were not originally designed with a finer grain
permission framework in mind can be bludgeoned into adopting one.

A fifth way: SELinux doesn't really work in an extensible capability
system. When it is possible to introduce new capabilities with new
operations (types) that were not anticipated by SELinux, well, you're out
of luck. This is basically a "layering of abstractions" problem, and in the
general sense I'm not aware of any good solution.


Finally: an under-appreciated feature of SELinux is that audit complaints
yield bug reports yield application evolution toward narrower authority.
Getting a feedback mechanism placed on developers in this regard is a very
good thing.


SELinux is complicated. As Rob notes, AppArmor is in practice much more
useful by mere mortals, though this is partly because AppArmor doesn't try
to bring all system operations under a single framework.

The overriding problem with SELinux is that both the operational mechanism
and the policy modules are altogether undocumented, and there is no good
guide that describes its theory of operation and how to drive it as a tool.
Locally defined policies are prone to be broken by core policy upgrades,
which can be a nuisance.



Jonathan

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk