[Cialug] apache security question

[Josh More]

It might be easier to think of it as Discretionary Access Controls (DAC)
vs Mandatory Access Controls (MAC).  In the "classic" system, the person
who is using the data has the ability to set the security levels on the
data.  Hence, the ability to run "chmod" and such.  There is also an
administrative user who can assign users and groups to that data.  The
problem here is that users who have the ability to read the data are
automatically trusted with the ability to allow (or disallow) other
people to read the data.  Traditionally, in the *nix world, this hasn't
been a huge issue, as most people are generally trustworthy.

However, in large corporate and military environments, there is a
cultural need to limit access.  Moreover, in a distributed environment
(such as the Internet), there is another class of user that includes
both untrusted users (browsers) and untrustworthy users
(hackers/crackers/script kiddies).  In the MAC model, an individual sets
the security level of data when it's created.  The system should then
prevent it's modification and access based on the types of users and
accesses being attempted.

That's all well and good in theory, but it's a royal pain in the ass in
real life.  If you are building a highly-secure system, you tend to have
the security roles and groups well defined for all users, applications,
system daemons and locations.  Most of us (myself included) tend not to
design to that level in the day to day.  Thus, you have vendors like Red
Hat who try to come up with a standard set of permissions that is both
secure and easy to use.  In the Red Hat world, they simplfy things by
making the default system admin account be the same as the default
system security account.  Thus, the root user can run SELinux commands
to fix the oddities that MAC imposes on a DAC system.  In effect, by
doing this, they have plugged all the annoying aspects of MAC into a
system that has an aggregate (and aggravating) security level of a DAC
system.

If you truly want a secure system, you should split the root account and
the SELinux admin account and treat security as completely separate from
normal system administration.  Alternatively (and my personal favorite),
you can leave SELinux mostly disabled, and only enable it for certain
container-level uses.  I find that AppArmor does this quite well.

In that model, you have your standard easy-to-administer DAC system,
with little hardened "islands" in it.  Typically, these are Apache
virtual hosts, Tomcat virtual hosts, email servers, etc.  For these
protected apps, the kernel limits what each can do, and is ideally
configured to log access violations in a non-centralized manner (By
which, I mean each island has it's own log.  Ideally, these logs should
be on another centralized server.).  That way, a user who is not
security-trained can admin the system according to best practices, and a
security administrator can protect the actual data without knowing the
details of what the entire system is up to.

I suspect, however, most of us work for companies that are either too
small or too open to really implement something like that.  I just hope
that this makes a bit more sense than thinking of them as "new" and
"legacy" permissions.  They are two different models and each model is
useful in its own right.

If you read this far, you get a cookie.  I've put it in Firefox for you.
 :)



-Josh More, RHCE, CISSP, NCLP, GIAC 
 morej at alliancetechnologies.net 
 515-245-7701

>>> Jeff Chapin <chapinjeff at gmail.com> 07/03/08 4:56 PM >>>
> Interestingly, that never occurred to me. I guess I have always viewed

> selinux as a directory level thing -- this is my documentRoot for 
> apache, it gets such and such permissions, etc...
> 
> I think part of that is the divide between selinux permissions and 
> 'classic' permissions. If the selinux permissions showed up in ls -la,

> for instance, it would seem a little more harmonious... And I would
use 
> it much more, as I tend to forget about it.