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

Andy Lutomirski luto at amacapital.net
Sat May 10 00:38:49 UTC 2014


On Fri, May 9, 2014 at 5:23 PM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Fri, 2014-05-09 at 13:37 -0700, Andy Lutomirski wrote:
>> On Fri, May 9, 2014 at 11:22 AM, H. Peter Anvin <hpa at 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.
>
> I think we should stop focussing on this case because firstly it's
> second guessing what we actually have to do and secondly there might be
> a solution on the horizon for Secure Boot which removes the issue.  As I
> said, I'll try to have non uefi confidential details by the time KS
> rolls around.
>
>> 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!
>
> I can be agnostic on this.  What I want is something that gives my
> internet attached server more security ... in particular, if someone
> breaks in I want them to be able to do as little damage as possible.
> The reason I'm agnostic is that I have had several break in's over the
> past decade I've been running my own colo hosted system.  None actually
> managed to escalate to root (so any root security wouldn't have helped).
> The problem for me was that they managed to do enough damage without
> being root (one even managed to get apache to send out masses of spam
> leaving me with a huge cleanup operation ... lesson learned, I now have
> an iptables OUTPUT rule rejecting any non postfix traffic to port 25 and
> alerting me to the attempt).
>
> The point is I like the theoretical idea of protecting my system from
> someone who manages to escalate to root and hey, if it can be done
> easily, I'll take it, but that's not usually my biggest problem when I
> consider security.

We're almost at the point where it would be reasonable to shove
basically every service on a system into a user namespace, in which
case, barring bugs, you shouldn't be able to own the kernel.  I wonder
if this might do pretty much exactly what you want.

Essentially, you'd mount your filesystems, make a new userns, move all
network devices into a new netns owned by that userns, unshare the
mount namespace, and somehow get systemd or whatever other init
program you're using to play along.

If you're just trying to protect the kernel, you can even map all uids
straight through, including root.

The major annoyance is that it's damn near impossible to mount real
filesystems (i.e. not tmpfs) from inside a userns.  There could be a
daemon outside that helps out.

This doesn't necessarily do anything sensible with device nodes, but
that might not matter for servers.

--Andy


More information about the Ksummit-discuss mailing list