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

["H. Peter Anvin" <hpa@zytor.com>]

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.

Once you have the separation you can define exceptions.

	-hpa