In defense of Mandatory Access Control, was Re: No more Novell AppArmor?

[Travis <travis+ml-dailydave () subspacefield org>]

Okay so I'm reading up on really old email, but I had to comment
on this:

On Sun, Oct 14, 2007 at 09:19:22PM -0700, J.M. Seitz wrote:
> Oh lord, don't even get me started with the AppArmor/SELinux craziness. I
> can't remember if it was InfoSec magazine, but Crispin and some other dude
> went head to head on SELinux vs. AppArmor. By the end of the article it was
> clear that neither are really useful, they are impossible to configure
> correctly (something like 700+ policy lines for SELinux and httpd) and in
> most cases are shut off. I know it's policy where I come from to do a
> "setenforce 0" the minute we bring up a new machine :)

I've used SELinux with Fedora Core, and now I am apparently using
AppArmor with Ubuntu, and systrace on OpenBSD.  It seems that I may
have a bit more experience with MAC systems than average, so I wanted
to share my experiences.

I read through most or all of the documentation for SELinux.  It's
hard to read the documentation, because it keeps referring to (IIRC)
subjects, objects, actions, and types, and they're all defined in
terms of each other.  Once you get over the hurdle of the circular
references, it's not exactly well written, or entertaining, but it's
straightforward enough.

With Fedora Core, running SELinux was a breeze.  IIRC, every package
came with its own SELinux profile, and so the only configuration I had
to do was for the fact that I had postfix calling procmail which was
calling the MH program rcvstore to store my email, possibly on an
NFS-mounted partition (bad idea generally but it fit my home network
design at the time).  Because normally daemons shouldn't get to
execute arbitary programs off the file system - for obvious
least-privilege reasons.  Once you understood the policy language, it
was a trivial change.

There are three policies provided; targeted, strict, and MLS.
Targeted provides restrictions only on daemons that listened on the
network, which was important at the time it was developed because
there were a lot of server-side attacks being published back in those
days.  With SSH, once you got in and executed a shell, you essentially
entered an unrestricted mode (with one restriction; you couldn't mess
with the policy directly).  Strict actually restricted what you
could do everywhere, even at the command line and logged in as root.
These two were based on Type Enforcement, also called Domain Type
Enforcement.  You can probably find papers if you google for those.
MLS basically adds in the Bell-LaPadula model, so that Secret programs
produce Secret data, and can't read Top Secret data.  I never ran it
in this mode, because having data at different security levels seemed
like too much work to me.

Regarding the comment that the number of lines of policy configuration
was very large, you have to understand that SELinux provides *very*
fine-grained protection.  I won't say it could provide access controls
on *everything* you might want, because I'm sure there are some
examples (perhaps related to networking and signals) that may be
missing, but it is a very significant, major leap over the normal Unix
permissions (discretionary access controls - DAC).  In fact, IMHO it
makes the Unix discretionary access controls completely superfluous.
I can't think of anything off the top of my head that could be done
with DAC that couldn't be done with MAC.

Now, when you have fine-grained permissions like this, it seems
altogether unavoidable that the policy that you use to configure these
permissions is complex.  That's because you're doing things like
confining sets of programs to only be able to access certain sets of
files in certain ways, and the more of these sets of things you have,
the longer the policy is going to be.  They have done some work in
making this easy, but perhaps more work could be done.  In part, it
reminds me a bit of how high-level languages allowed for much more
code re-use than assembly language, and how object-oriented languages
provided even more productivity gains, because inheritance in
particular allowed for more, easier code re-use.  Perhaps a similar
evolution could occur in policy languages.

However, saying that it is impossible to correctly configure a
program's policy because the policy is 700 lines long is equivalent to
saying that it is impossible to write a 700 line computer program that
works properly, or write a valid 700 line mathematical proof.  It's
clearly not impossible; it just takes understanding, some patience,
and some learned skill.  The more understanding and skill you have,
the easier it is.  What _is_ impossible is writing a correct policy
without understanding SELinux itself and not having a rough
understanding of what the program might need to do to other files and
programs.

A web server is a perfect example of a program that's hard to
configure with a minimum amount of privileges, because it is a network
daemon that deals with a huge base of essentially anonymous,
potentially untrustworthy users, has to run programs off the local
file system (CGIs), write to log files, read files in the webroot,
etc.  Many web site provide something close to a primitive desktop
full of applications, and writing a really minimal policy for that
would be a non-trivial task, and would require updates as the
underlying needs change.

I should mention, the less fine-grained you want your privileges, the
smaller the policy file may be.  It is easy to drop a policy in that
says a program can do anything.  It's a bit more work to specify in
detail every class of object it might touch, and what it is allowed to
do to those classes of objects.  As you increase in skill, you can
increasingly tailor the policy of any given program, to come closer to
matching the minimum privileges it may need to execute.  (I am aware
that the wikipedia article states that SELinux's goals are unrelated
to the principle of least privilege, but IMHO it does allow for heavy
restriction of privilege, whether by design or not, and this is a good
thing).

What is clear is that this takes a deeper level of understanding than
simply running the program with no policy at all.  I too have worked
in an environment (a web hosting provider) where they immediately turn
MAC enforcement off.  That's fine, that's why the functionality can be
turned off; not everyone cares about security enough to want to invest
that level of attention into policy configuration.  Certainly it is
far beyond the skill of your typical PHP developer; I would not say
it takes a security expert to configure it, but it does take a day
of reading and a certain mindset that is unrelated to "how do I get
my program to work?" - more like "what is the minimum set of privileges
that my program needs to work?".

DAC has a problem that a user can unwittingly destroy his own
security; for example, he could accidentally make his .profile
world-readable.  I have used ISPs back in the day where they had a
problem with users writing IRC bots, which was against their policy -
I don't recall exactly why, but I don't recall their concern as being
unreasonable.  Certainly such a user could also unwittingly provide
unlimited access to his entire account if the bot were improperly
coded (e.g. buffer overflow).  There is no easy way in a traditional
Unix system to either prevent users from writing and running servers,
or to limit the amount of things a compromised server could do, beyond
running it as an unprivileged user.  IMHO, the whole idea of
unprivileged pseudo-users is a hack - they aren't real users - which
points to a pervasive weakness in DAC models.  And quite often it is
done wrong; several servers may be running as "nobody", meaning that
compromising one can allow you to interact with the other program
running as the same UID.

I appear to be running AppArmor in Ubuntu, and despite a few messages
in the kernel message queue, it seems to be working fine with no
configuration whatsoever.  I haven't really looked into it much, since
I just installed Intrepid within the last few weeks, but it does look
like it's close to a "zero effort" for the sysadmin, assuming that it
is even enforcing anything.

I also run systrace in OpenBSD; IIRC, the ports system runs this
automatically when building a port.  I have done a little bit of
research on systrace, but have not written any policies.  Again, no
configuration was needed on my part as a sysadmin.

So, in a nutshell:

1) The complexity of policy is directly related to how fine-grained
you want your access control to be.  This is an unavoidable cost,
but varies depending on how precise you want to be.

2) Not everyone cares enough to lock down what programs can do, but
it's nice to be able to do so if you do.  It may not be a money-making
idea for web hosting providers, but it makes good sense to me for
financial institutions with a web presence, the military, and security
defenders, if they're serious about protecting their assets.

3) When the policies come with the programs, it tends to not be a
problem for end-users who aren't doing network application
development.

4) The MAC implementation I am most familiar with (SELinux) is more
powerful and expressive than DAC, and in theory could replace it
entirely, especially if you're the policy admin, sysadmin, and the
only legitimate Unix user on the server.

I realize I've written quite a bit about this, but after seeing
security experts discussing minutia of reverse-engineering and address
space layout randomization and W^X and NX and stackguard and so on,
I'm a bit surprised about seeing so many people being snarky about
such a powerful security technology.  I guess I'll just have to chalk
it up to cynicism about any new protective technologies; it's cool to
be dismissive and aloof.  If you can find major areas it doesn't
cover, you can call it ineffective.  But if it actually tackles a
inherently complex job in an effective way, you can say it's too
complex.  If you get called for laziness on that, simply say it's too
complex for the average user to use properly.

As long as the policies come with the applications, I'm not sure that
any of these are the case.

Of course it's more complex than running everything as root; enforcing
least privilege gets more complex the better you do it.  Modern
operating systems and applications are inherently complicated.  But
that doesn't make them an inherently bad idea.

"Make everything as simple as possible, but not simpler."
        -- Albert Einstein

-- 
Obama Nation | My emails do not have attachments; it's a digital signature
that your mail program doesn't understand. | http://www.subsubpacefield.org/~travis/ 
If you are a spammer, please email john () subspacefield org to get blacklisted.

Attachment: _bin
Description:

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave