Re: Penalty of SELinux?
On Tue, 25 Sep 2007 05:04:15 -0400, Kevin Mark <kevin.mark@verizon.net>
said:
> There are 2 approaches to application security that I am aware of:
> app-armour and SELinux. Debian has SELinux, although Ubuntu now has
> both and seems to be favouring app-armour for some odd reason that I
> have not investigated. If Ubuntu continue, it could be another rift
> with unknown consequences. I have read about more distros supporting
> SELinux than app-armour. I have also read some on SELinux and of the
> discussions of it on -devel and seem to think its the way to go.
> Hopefully sometime in the near future we will have either a targeted
> or strict policy that is usable for average web server use in one or
> two releases that is not as complicated as it is now. IIRC the folks
> on that mission include Manoj and Eric Shubert. who I wish well on
> that AVC filled road. Cheers, K
App Armour is smoke and mirrors, and does not really provide
security, in my opinion -- since it is oh so very easily
bypassable. People in the security field believe that pathnames are an
inappropriate security mechanism.
Label-based security (exemplified by SELinux, and its
predecessors in MLS systems) attaches security policy to the data. As
the data flows through the system, the label sticks to the data, and so
security policy with respect to this data stays intact. This is a good
approach for ensuring secrecy, the kind of problem that intelligence
agencies have. Labels are also a good approach for ensuring integrity,
which is one of the most fundamental aspects of the security model
implemented by SELinux.
SELinux security is enforced within the kernel, and an
application which does not have permission to access an object will
simply receive an error using the standard Unix mechanisms already
used for DAC. For example, a write(2) might fail with an EACCES error
code.
Traditional Unix security in fact does not primarily depend on
pathnames, but on DAC ownership and permission attributes stored in
the file's inode. DAC is of course a form of labeled security.
Pathname-based security (exemplified in AppArmor, and its
predecessor Janus http://www.cs.berkeley.edu/~daw/janus/ and other
systems like Systrace http://www.citi.umich.edu/u/provos/systrace/ )
try to get by with a half hearted attempt by attaching "security"
policy to the name of the data. Create a symlink, bind mount, or
anything like that, and poof, there goes your security. In other
words, namespace manipulation, object aliasing (e.g. symlinks),
application error, configuration error, corrupted files, corrupted
filesystems, misbehavior due to malware infection or various forms user
error makes security go away. A pathname tells you nothing reliable
about the security properties of the object its pointing to. It is
simply a mechanism for locating and referring to an object.
In fact, I am not sure how you can provide integrity support
without labels. AppArmor confines a process, but does not effectively
confine its output files, precisely because the output files are not
labeled. Other processes are free to access the unlabeled, potentially
malicious output files without restriction. Without security labeling
of the objects being accessed, you can't protect against software
flaws, which has been a pretty fundamental and widely understood
requirement in general computing for at least a decade.
You need a way of providing global and persistent security
guarantees for the data, and per-program profiles based on pathname
don't get you there. There is no system view in AA, just a bunch of
disconnected profiles.
Bad security is dangerous, really dangerous.
As an aside on the penalty of SELinux, the upfront labeling cost
of labeled MAC is not characteristically different to that of
traditional DAC labeling. Ideally, an SELinux system is installed from
scratch with its security labels as well as DAC attributes, with the
labeling behavior for newly created objects being controlled from a
well defined policy. You probably want to avoid getting into the
situation of needing a TE relabel on a production system in any case.
manoj
getting off the soap box
http://www.nsa.gov/selinux/papers/inevitability/
--
I'm a Hollywood writer; so I put on a sports jacket and take off my
brain.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: