Re: How to make module autoloading play nice with securelevel

[Gary Thorpe <gathorpe79%yahoo.com@localhost>]

Would it be useful to use digital signatures with kernel modules and have the 
user decide which signatures are "trusted" (including the options of accepting 
any or unsigned modules [all])? Is it infeasible, too hard or not very secure 
to do this?

It seems using something similar would allow the user to sign module he/she 
builds or install third party modules that they trust without having to worry 
about the file system (where the modules are stored would be arbitrary) and 
whether or not the module has been modified after it was signed.

The problem is how to ensure kernel integrity and system security while 
allowing module loaded: digitally signing the modules seems like it would be 
useful if one wanted to allow more choice than a) disallow all module loading 
or b) allow any arbitrary module to be loaded.

Gary

--- On Sat, 10/16/10, Thor Lancelot Simon <tls%panix.com@localhost> wrote:

From: Thor Lancelot Simon <tls%panix.com@localhost>
Subject: How to make module autoloading play nice with securelevel
To: "Paul Goyette" <paul%whooppee.com@localhost>
Cc: "David Holland" <dholland-tech%netbsd.org@localhost>, 
tech-kern%NetBSD.org@localhost, tech-security%netbsd.org@localhost
Received: Saturday, October 16, 2010, 4:26 PM

On Sat, Oct 16, 2010 at 01:17:47PM -0700, Paul Goyette wrote:
> On Sat, 16 Oct 2010, David Holland wrote:
>
>> > And also make the "blessed" directory itself immutable?  :)
>>
>> As I recall the semantics of immutable are such that this isn't
>> necessary to protect modules that are present at boot time (that is,
>> they can't be unlinked/renamed/etc.), and if there are autoloadable
>> modules whose names aren't present at boot time, they'll fail the
>> check.
>
> I've already misread the code here once, but...
>
> As far as I can tell, each time a module_autoload call is made, if the  
> module is neither built-in nor passed in by the boot loader, the code  
> will attempt to load it via a call to kobj_load_vfs() which has path as  
> an argument.  It doesn't appear to me that there is any pre-approved  
> list of acceptable objects that can be loaded from the file system.

Right, it's looked up by path.  And this is a problem: you need to make
sure all directories from which modules can be loaded are immutable at
boot time, which is harder than you'd think because it's not just one
directory!  If it were a flat directory of files, it'd be a lot easier.

And then there's the mount-on-top issue.  Jared had a very elegant
suggestion for this: record which device the module autoload root
directory is mounted on at boot time.  At autoload time, check that
the module you're about to load does in fact come from that same device.

I wish I could think of some similarly elegant solution to the "have to
mark everything from the module root down to the modules themselves
immutable -- and check it before enabling autoloading, at boot time"
issue.  But I can't see a way that doesn't require building the whole
hierarchy of autoload-eligible files at boot time.  Can you?

> BTW, does the immutable flag prevent one from using an immutable  
> directory as the mount-point for some other file system?  Hmmm...

I think it's an interesting question whether it should.  I'd tend towards
"yes, it should" but the answer right now is "no, it does not".

This is all useful and important functionality.  We should get it all
working together and try to keep it that way.  I cannot lose the feeling
that there's a non-Baroque solution lurking out there that we just haven't
quite landed on yet.

Thor