public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hch@infradead.org, jmorris@namei.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk,
	kees.cook@canonical.com
Subject: Re: Preview of changes to the Security susbystem for 2.6.36
Date: Wed, 04 Aug 2010 12:23:47 -0400	[thread overview]
Message-ID: <6936.1280939027@localhost> (raw)
In-Reply-To: Your message of "Wed, 04 Aug 2010 16:00:21 +0900." <201008040700.o7470LWi021902@www262.sakura.ne.jp>

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

On Wed, 04 Aug 2010 16:00:21 +0900, Tetsuo Handa said:
> Valdis.Kletnieks@vt.edu wrote:
> > Are you sure you weren't running in permissive mode when you tested this?
> I'm running CentOS5.5 and RHEL6beta in enforcing mode with default configuration
> (TARGETED policy).
> 
> > I am unable to replicate this behavior on my system with SELinux set to
> > enforcing mode.  However, it does happen (which is to be expected) when SELinux
> > is set to permissive mode.
> So, MLS policy can stop this case, can't it? That's fine.

Apparently so.

> But most people is using TARGETED policy, isn't it?
> How do you provide protection to those who don't use MLS policy?

I'll point out that the requirements to even *start* sshd in the MLS policy are
much more stringent - basically, running /usr/sbin/sshd on the command line
doesn't work because it can't transition from your context to the sshd context.
Only init context to sshd is allowed.

More crucially, your "breakage" is actually a non-issue, because under the
targeted policy, launching sshd with a parameter that results in /etc/shadow
being disclosed requires you to be root in pretty much any security context
including unconfined_t - at which point you can access /etc/shadow *anyhow*.
Who the hell actually *cares* that you can go through all the trouble of
restarting sshd and then ssh'ing in to get a copy of a file, when you could
just as easily 'cat /etc/shadow'?

So what you're saying is that SELinux sucks because it doesn't prevent people who
have a legitimate copy of the front door key from climbing in a third floor window.

Remember what I said about having a *model*?  For MLS, the model includes "/etc/
shadow is only accessible to specifically authorized processes".  So care is
taken to close down any and all side doors like asking sshd to do the dirty
work for you.  For the 'targeted' policy, the model is "Only a specified list
of network-facing daemons is confined", and no care is taken to prevent
authorized users from accessing files they already have legitimate access to.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2010-08-04 16:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-30  8:59 Preview of changes to the Security susbystem for 2.6.36 James Morris
2010-08-02  2:18 ` James Morris
2010-08-02  6:32   ` Kees Cook
2010-08-02  6:41     ` James Morris
2010-08-02  6:57       ` Kees Cook
2010-08-02 10:19         ` Christian Stroetmann
2010-08-02 16:36           ` Kees Cook
2010-08-02 17:33             ` Christian Stroetmann
2010-08-03 17:07               ` Kees Cook
2010-08-02 18:08           ` Serge E. Hallyn
2010-08-02 18:50             ` Christian Stroetmann
2010-08-02 12:24   ` Christoph Hellwig
2010-08-02 16:59     ` Kees Cook
2010-08-02 18:34       ` David P. Quigley
2010-08-03 17:04         ` Kees Cook
2010-08-02 18:51       ` Valdis.Kletnieks
2010-08-03 16:50         ` Kees Cook
2010-08-03 21:38           ` Valdis.Kletnieks
2010-08-03 22:34             ` Kees Cook
2010-08-04  2:07               ` Valdis.Kletnieks
2010-08-04  2:55                 ` Kees Cook
2010-08-04  3:54             ` Tetsuo Handa
2010-08-04  6:18               ` Valdis.Kletnieks
2010-08-04  7:00                 ` Tetsuo Handa
2010-08-04 16:23                   ` Valdis.Kletnieks [this message]
2010-08-04 12:21               ` Christian Stroetmann
2010-08-03 21:52           ` Christian Stroetmann

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=6936.1280939027@localhost \
    --to=valdis.kletnieks@vt.edu \
    --cc=hch@infradead.org \
    --cc=jmorris@namei.org \
    --cc=kees.cook@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=viro@ftp.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox