Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions

[Andy Lutomirski <luto@amacapital.net>]

On Fri, May 9, 2014 at 11:22 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/06/2014 10:31 AM, Andy Lutomirski wrote:
>>
>> I have two main objections to "root != kernel".  The bigger is that
>> I'd like to see the security argument for it so that people can think
>> about whether it makes sense.  The smaller is that "root != kernel"
>> isn't necessarily well-defined.
>>
>> For example, should root be able to write to the filesystem from which
>> the kernel loads?  Should root be able to kexec a new kernel, if that
>> clears some key known to the current kernel in the process?  Should
>> root be able to start a KVM instance that passes essentially all
>> hardware through?  Should root be able to talk directly to the
>> system's embedded controller?  Should root be able to read all
>> physical memory?  How about reading just enough to learn the kernel's
>> semi-secret randomized addresses?  How about running perf without
>> restrictions?
>>
>> In the past, the actual security goal seems to have been "root shall
>> not be able to do anything that would anger Microsoft and/or
>> Verisign", which is far-enough removed from actual security that I
>> don't want it anywhere near my system.  But if I could have a
>> reasonable policy that "root shall not be able to persistently
>> compromise the machine", then I think this could be great.
>>
>> Note that the latter goal does not actually require that root be
>> unable to modify the running kernel.
>>
>
> The first aspect of this is that the kernel needs to *be able to* lock
> out root from select functions.  These things will be system
> configuration dependent.
>

I'm still unconvinced.  For Chrome OS-style security, I think that
root just needs to be prevented from doing anything that will
interfere with the verified boot process the next time the machine
boots.  The kernel doesn't need any particular security feature for
this: the kernel can't change the verified boot keys either.  If an
attacker controls root on a Chromebook, the attacker has already won,
at least until the next reboot.

If the idea is to have a verified boot without any hardware or
firmware support, then, yes, the kernel needs to enforce that the
verification path can't be tampered with.  But I think we're talking
about Secure Boot here, and on a correct Secure Boot implementation*,
the worst that the kernel can do is to prevent the box from booting
next time.

The best arguments I've heard so far for why the kernel needs to try
to protect itself against root are:

1. MS/Verisign demand it.

2. It's annoying to fool a user into thinking that they just booted
Some Other OS when they're really running Linux without kernel help.
NB: no one has claimed that it's impossible AFAIK, just that it's
annoyingly complicated.

I like neither of these arguments.  #1 is politics, not security, and
#2 seems like security by annoying the attacker.

To be clear, I don't object on principle to making it possible for the
kernel to defend itself against root.  But it's hard, doing it right
will require a lot of care, and I don't think it's worth doing unless
there's a good reason.  If there's a good reason that I don't know
about, please tell me!

* The recent MITRE paper suggests that very few of these exist.
That's a separate issue.

--Andy