Date:	Sun, 27 Dec 2009 05:56:14 -0500
From:	Valdis.Kletnieks@...edu
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	serge@...lyn.com, serue@...ibm.com, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: A basic question about the security_* hooks

On Sun, 27 Dec 2009 13:02:54 +0900, Tetsuo Handa said:
> I believe TOMOYO can safely coexist with other security modules.
> Why TOMOYO must not be used with SELinux or Smack or AppArmor?
> What interference are you worrying when enabling TOMOYO with SELinux or Smack
> or AppArmor?

(It's 5AM and I just got woken up by a thundering herd of cats and can't
get back to sleep, but there's no caffeine to be found.. Yee hah)

Sure, it's *possible* to create a system where you've loaded 2 security systems
and have it work.  But the general consensus is that if you're running one
system and want to run a second, it's easier to ask yourself *why* you want to
run the second, and see if there's some way to get the added functionality
supported in the first system. Presumably your reason is of the form "I'm
running XYZ, but it doesn't stop attack ABC like ZQW does".  Usually, the right
answer is to fix XYZ, not try to load ZQW on top of it.  But if you insist.. ;)

The basic problem is that large complete MAC systems like TOMOYO, SELinux,
Smack, or AppArmor are complicated.  In addition, they are unable to look at
each other's policies to detect potential conflicts. As a result, although
it's probably *possible* to create a system that loads both a TOMOYO and
an SELinux policy, it's hazardous:

First, it's possible to totally screw up your box - consider 2 defective
policies where each prevents a reload of the other's policy.  Now note that it
doesn't even need to be the *policy* - if the Tomoyo policy files get
mislabeled with the wrong SELinux context, then an SELinux component will
probably prevent access to the policy and thus prevent the load.  Your system
is now *at best* running SELinux-only (and now vulnerable to to any attacks you
were depending on Tomoyo to stop). At worst, the wrecked Tomoyo policy will
mean that Tomoyo will then reject the SELinux 'restorecon' command to correct
the labels, leaving you in a situation where you can't recover your box.

Second, it's unclear what a combo of two different MAC systems would *mean*,
and whether it creates corner cases that can be exploited - the "two systems
block each other's reloads" mentioned above is but one example. If a system that
depends on inode labeling is active at the same time as a path-based system,
what happens if you manage to do an 'mv' command that changes the security
context in the path-based system while leaving the inode label the same, or
relabel an inode without rename it to match? The file has just experienced
a security transition for one system, but not the other. Are there any
files and transitions where the mismatch matters?

If the two systems load policies with the same semantics, why are you
bothering?  And if they load different semantics, can the difference be
leveraged by an attacker?

In addition, we've already actually seen composition bugs before - when a
program expecting standard Linux DAC failed when it hit the composition of DAC
plus capabilities. It's helpful to go re-read the story of the Sendmail
capabilities bug, where the Sendmail code wasn't capability-aware, and thus
didn't forsee any way that doing a setuid()/setgid() while running as root
could possibly fail. When it *did* fail, Sendmail thought it was running as a
mortal, but actually still had all privs. Hilarity ensues.

The problem is that for you to *really* be able to safely compose (for instance)
Tomoyo and SELinux, you need to go through *every* Tomoyo-aware program and
verify "this will Do The Right Thing even if an SELinux policy unexpectedly
fails us here" at every point - and then repeat for every SELinux-aware
program regarding a Tomoyo-induced rejection.

And then you get to repeat the process for each Tomoyo and SELinux *policy*
you want to use...

Like I said - it's usually more sane to go back and re-evaluate *why*, and
see if you can fix one system or the other to address your needs.




Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists