Re: Trusted kernel patchset for Secure Boot lockdown

[Matthew Garrett]

On Fri, 2014-03-14 at 17:06 +0000, One Thousand Gnomes wrote:
> > But you keep talking about MSRs despite there being a patch that limits
> > access to MSRs. If you have specific examples of privilege escalations
> > that are possible even with these patches then please, mention them.
> 
> I mentioned MSRs once, and then you kept going on about it. 

You've twice mentioned MSRs as a case where CAP_SYS_RAWIO allows you to
elevate privileges, despite that being a case that's explicitly covered
by this patchset. Now, do you have an actual example of CAP_SYS_RAWIO
allowing you to elevate privileges even with this patchset applied (and
without requiring the presence of obsolete hardware, which is a separate
conversation)?

> Your patches are all over the tree, for what should be one piece of
> policy. They rely on not missing a single case, which is also bad
> security engineering. We know that, as an industry we've spent fifty
> years repeatedly sticking our fingers in our ears, refusing to listen and
> then learning it again and again the hard way.

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.

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.

> > 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.

> > ...thus breaking userspace outside this use case. I mean, sure, I'm
> > absolutely fine with deleting /dev/mem entirely. I don't see Linus
> > agreeing.
> 
> That's not what I meant. We have a lot of interfaces where we use
> CAP_SYS_RAWIO rather than having a structured interface as opposed to a
> 'yeah whatever, poke the registers' interface.
> 
> For a lot of environments btw you don't actually need /dev/mem. It's not
> really got a lot of uses any more and plenty of people really restrict or
> remove it from systems. I don't think very many people would be sad
> if /dev/mem became a legacy interface most people left turned off.

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. 

> 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.

-- 
Matthew Garrett <matthew.garrett@xxxxxxxxxx>