linux-kernel - Re: Trusted kernel patchset for Secure Boot lockdown

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]

Message-ID: <20140313232140.03bdaac3@alan.etchedpixels.co.uk>
Date:	Thu, 13 Mar 2014 23:21:40 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown

On Thu, 13 Mar 2014 21:30:48 +0000
Matthew Garrett <matthew.garrett@...ula.com> wrote:

> On Thu, 2014-03-13 at 21:24 +0000, One Thousand Gnomes wrote:
> 
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
> 
> How?

You want a list... there are load of places all over the kernel that have
assumptions that RAWIO = safe from the boringly mundane like MSR access
to the more obscure driver "this is RAWIO trust the user" cases of which
there are plenty.

If you are going to do something "secure" then do it *right* otherwise
you are not actually implementing anything, just making fake security
noises.

SELinux required user space changes, fiddle with CAP_SYS_RAWIO will need
userspace changes IFF you want to run 'secure' mode. That I think is
acceptable.

You can even avoid the userspace issues with a small amount of checking.
If you don't want to touch capability sets then make the default
behaviour for capable(x) in fact be

	capable(x & ~secure_forbidden)

for a measured kernel and add a 

	capable_always()

for the cases you want to not break.

As for mem= and exactmap, it has nothing to do with /dev/mem and
everything to do with giving the kernel a memory map where some of the
space it thinks is RAM is in fact devices, rom, space etc. If the kernel
is given a false memory map it will misbehave. Exploitably - well given
the kind of things people have achieved in the past - quite possibly.

If you are not prepared to do the job right, then I don't think it
belongs upstream. Let's do it right, and if we have to tweak a few bits
of userspace to make them work in measured mode (but without breaking
anything in normal modes) then it's worth doing the job properly.

I don't think we need to break any userspace for "normal" mode to do
this. Userspace in measured mode is going to change anyway. It already
has just for things like module signing.

(As an aside you may also then want to think about whether you allow
measured userspace elements that secure_forbidden is considered to be 0
for so you can sign userspace apps that are allowed to do RAWIO)

Alan
--
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/