Re: Trusted kernel patchset for Secure Boot lockdown

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> The command line problem here is a total red herring. If you've got a
> measured kernel, you have a measured command line. (If not, you don't

That would be the sensible approach, but it has some quite drastic
ramifications.

> have a measured kernel.) Dealing with the command line has nothing to
> do with enforcing the ring0/uid0 boundary which is what this patch
> series does.

It has a huge relevance. You are signing blocks of code and loading them
into your kernel. In case it's escaped your notice those blocks of code
have behaviour which is considerably customisable by passing module
arguments to them. In many cases they don't actually check those
arguments. If I can set module paramters I already 0wn your box so many
different ways its not even funny.

> Right. As mentioned, we've been over all of this before. We cannot
> change the meaning of capabilities (nor expand their coverage to
> existing interfaces) without breaking userspace. Since we cannot break
> userspace, we must create a different policy system that covers this
> new thing we want to do and keeps the new policy distinctly separate.

So you have everything checked twice all over the kernel and you
guarantee that people will get it wrong. I don't see the point of putting
a broken implementation in the kernel. If you want to do security do it
*right* and do it once. You think every single person who adds a driver
is going to muddle through two interfaces (and in future no doubt more if
we don't fix it properly) and get it right each time ?

The 'breaking userspace' argument is bullshit already. The whole *point*
of the measured kernel is to break userspace. You are deliberately
breaking a pile of functionality, much of it undersirable in order to
achieve your measured system.

The only "don't break" case that matters is if the measured stuff isn't
in use. In those cases we don't need to break anything.

Alan