linux-kernel - Re: mmap_min_addr and your local LSM (ok, just SELinux)

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jul 2009 13:45:31 +1000 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Eric Paris <eparis@...hat.com>
cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Stephen Smalley <sds@...ho.nsa.gov>, spender@...ecurity.net,
	Daniel J Walsh <dwalsh@...hat.com>, cl@...ux-foundation.org,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, kees@...flux.net
Subject: Re: mmap_min_addr and your local LSM (ok, just SELinux)

On Mon, 20 Jul 2009, Eric Paris wrote:

> Does anyone see a better way to let users continue to be users while
> protecting most people?  Yes SELinux is stronger in some areas than
> without confining the ability to map the 0 page, but as has be rightly
> pointed out it's foolish an broken that SELinux can weaken any
> protections.

I haven't seen a better idea so far.

I strongly believe that we need to maintain the principle, in SELinux and 
LSM generally, that the interface is restrictive, i.e. that it can only 
further restrict access.  It should be impossible, from a design point of 
view at least, for any LSM module to authorize more privilege than 
standard DAC.  This has always been a specific design goal of LSM.  (The 
capability module is an exception, as it has a fixed security policy and 
implements legacy DAC behavior; there's no way to "fix" this).

In this case, we're not dealing with a standard form of access control, 
where access to a userland object is being mediated.  We're trying to 
mediate the ability of a subject to bypass a separate mechanism which aims 
to protect the kernel itself from attack via a more fundamental system 
flaw.  The LSM module didn't create that vulnerability directly, but it 
must not allow the vulnerability to be more easily exploited.

The security policy writer should have a guarantee that the worst mistake 
they can make is to mess up their own security model; if they can mess up 
the base DAC security with MAC policy, we break that guarantee.  There's 
also an issue of user confidence in the LSM modules, in that they should 
not be any worse off security-wise if they enable an enhanced protection 
mechanism.

This does not account for kernel bugs in the LSM modules themselves, 
obviously, but the same can be said for any kernel code, albeit with less 
irony.

- James
-- 
James Morris
<jmorris@...ei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/