All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Valdis.Kletnieks@vt.edu
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	serue@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: A basic question about the security_* hooks
Date: Sun, 27 Dec 2009 08:54:28 -0600	[thread overview]
Message-ID: <20091227145428.GA19414@hallyn.com> (raw)
In-Reply-To: <22669.1261911374@localhost>

Quoting Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu):
> 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?

...

> 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?

Agree with everything Valdis said (including after this part, which I cut).

Why do you compose the two?  I assume you went to the trouble because
you have a specific use case, a definite advantage?

-serge

  reply	other threads:[~2009-12-27 14:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-24  2:29 A basic question about the security_* hooks Michael Stone
2009-12-24  4:50 ` Casey Schaufler
2009-12-24 12:53   ` Eric W. Biederman
2009-12-24 21:55     ` Tetsuo Handa
2009-12-25  0:05     ` Serge E. Hallyn
2009-12-31 17:50       ` David P. Quigley
2010-01-04  2:12     ` Paul Moore
2009-12-24  7:36 ` Evgeniy Polyakov
2009-12-24 18:57   ` Samir Bellabes
2009-12-25  0:14 ` Serge E. Hallyn
2009-12-25  1:11   ` Michael Stone
2009-12-25  5:50     ` Serge E. Hallyn
2009-12-26 19:50       ` Michael Stone
2009-12-27  3:16         ` Serge E. Hallyn
2009-12-27  4:02           ` Tetsuo Handa
2009-12-27 10:56             ` Valdis.Kletnieks
2009-12-27 14:54               ` Serge E. Hallyn [this message]
2009-12-27 20:28               ` David Wagner
2009-12-28  2:08                 ` Valdis.Kletnieks
2009-12-28 11:51               ` Tetsuo Handa
2009-12-28 14:45                 ` Valdis.Kletnieks
2009-12-28 14:51                 ` Valdis.Kletnieks
2009-12-29 13:01                   ` Label based MAC + Name based MAC (was Re: A basic question about the security_* hooks) Tetsuo Handa
2010-01-02 13:56                 ` A basic question about the security_* hooks Pavel Machek
2009-12-28 15:24         ` Kyle Moffett
2009-12-29  1:43           ` Casey Schaufler
2009-12-29 19:02             ` Kyle Moffett
2009-12-30 19:49               ` Casey Schaufler
2009-12-27  0:33       ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091227145428.GA19414@hallyn.com \
    --to=serge@hallyn.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.