Message-ID: <20140314214806.54a3d031@alan.etchedpixels.co.uk>
Date:	Fri, 14 Mar 2014 21:48:06 +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

> I have a set of patches that appear acceptable to the security
> maintainer. I've rewritten them multiple times in response to various
> levels of bikeshedding. They solve a real problem and are being shipped
> by multiple distributions.

And ? I've seen some of the other "extra" stuff distributions ship. Lots
of it is hilariously bad. That really isn't a good argument for the code
- for the feature yes.

> What the rest of your mail is asking me to do is to rewrite capabilities
> support entirely. Now, yes, I agree that capabilities are an awful
> interface that's approximately impossible to use correctly and which
> adds little security even if you do. But I reject the idea that
> rewriting fundamental security infrastructure should be a prerequisite
> for adding this functionality.

Actually it's nothing of the sort. It's a proposal to do it. It's 90% a
regexp task. I'm offering to go and do that bit. I am quite happy
to do the capability crapfest fixing. It wants doing *anyway*.

But if I got do that work, does it solve your problem ? I think it does
but I'd like to be sure.

> > > It needs to be possible for this policy to be imposed without userspace
> > > being involved, so using selinux would mean baking it into the kernel
> > > (along with an additional implementation for apparmor, and presumably
> > > one for tomoyo as well).
> > 
> > That's clearly false. You can load signed modules so you can load signed
> > policies. Assuming you don't have an initial measured file system you
> > need a kernel policy initially that protects you. If you have a measured
> > file system you don't even need that, nor do you need to revoke RAWIO in
> > kernel, you can do it before you switch into "measured and running
> > un-measured code" mode - ie about the point you pivot root out of the
> > initrd that loaded the measured policy.
> 
> We can't rely on userspace choosing to load that policy. We don't have a
> measured filesystem. The initrd is not signed (and nor can it be). The
> kernel itself *must* impose policy.

In your particularly implementation maybe you've got a weak setup where
you don't measure down to your initrd. That's a *flaw* in your
implementation. Don't inflict your limitations on others or on the
future. EFI is only one (and not a very strong one at that) implementation
of a 'secure' boot chain. A lot of other systems can not only propogate
measurement and security assertions into their initrd they can propogate
them into their rootfs (yes upgrades are .. exciting, but these kinds of
users will live with that pain).

Even in EFI you can make your kernel or loader check the initrd signature
and the rootfs signature if you want.

> Sure! Except then A Large Vendor's custom IPMI userspace stops working,
> even on systems without Secure Boot, and then said Large Vendor wants to
> have conference calls at times that are convenient for Japan and then
> this is an issue that's going to cause $1 billion in lost sales and come
> on, you've been there. You know that this isn't going to work. 

That's not an upstream problem (but with my work hat on I understand
your position). Anyway they'll be running someones enterprise product
which will have legacy enabled out of the wazoo so their customers 15 year
old "we lost the code" blob that nobody can even remember what it does
still works 8)

> > If we are going to do a measured kernel then it needs to be done right,
> > it needs to be properly abstracted so we don't add another one for
> > Android, another one for Chrome, another one for ARM trustzone, another
> > one for Intel SGX, and so on.
> 
> The fact that you keep saying measured really does make me suspect that
> you misunderstand the problem. There's no measurement involved, there's
> simply an assertion that the firmware (which you're forced to trust)
> chose, via some policy you may be unaware of, to trust the booted
> kernel.

You are currently using some of those interfaces for measuring to produce
a notionally 'trusted' initial loaded environment.

Correct me if I am wrong but your starting point is "I have a chain of
measurement as far as the kernel I load". Without that I can just go into
grub and 0wn you.

There are multiple things you want to do in measured environments,
stopping people sneakily loading new kernels is one of them. If you want
to talk about "secure" that implies a whole load more than ring 0 hacks.
It implies having a model where not only has J Random smart hacker gone
over the code and hacked all the call points, but that someone has done
some kind of formal review of it, used good security practices like
whitelisting and thought very hard about the rest of the exposed surfaces.

Otherwise its security theatre, it's marketing fluff. We've got lots of
marketing security fluff in the kernel, we don't need more of it.

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/

Powered by blists - more mailing lists