linux-kernel - Re: Preview of changes to the Security susbystem for 2.6.36

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6936.1280939027@localhost>
Date:	Wed, 04 Aug 2010 12:23:47 -0400
From:	Valdis.Kletnieks@...edu
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	hch@...radead.org, jmorris@...ei.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@....linux.org.uk,
	kees.cook@...onical.com
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

On Wed, 04 Aug 2010 16:00:21 +0900, Tetsuo Handa said:
> Valdis.Kletnieks@...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.

Content of type "application/pgp-signature" skipped