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 <t...@panix.com> wrote: From: Thor Lancelot Simon <t...@panix.com> Subject: How to make module autoloading play nice with securelevel To: "Paul Goyette" <p...@whooppee.com> Cc: "David Holland" <dholland-t...@netbsd.org>, tech-kern@NetBSD.org, tech-secur...@netbsd.org 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