Re: kernel module loading vs securelevel

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Oct 16, 2010, at 4:49 57PM, John Nemeth wrote:

> On Mar 8,  9:44am, Thor Lancelot Simon wrote:
> } On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote:
> } > 
> } > I'm just asking if "options INSECURE is mandaory to use autoloading,"
> } > not module/autoloading is secure/silly/boo or not.
> } 
> } No.  As far as I can tell, there's a bug in the relevant kauth listener,
> } at least in terms of the original intent of the author of the autoloading
> } code; the system scope kauth listener should return DEFER, not DENY.
> 
>     module_listener_cb() was added to kern_module.c in revision 1.51
> by elad.  The kauth_authorize_system() calls were added to
> kern_module.c by ad, but the respective commit log messages doesn't say
> anything about them, so the original intent of the author of the
> autoloading code (ad) is unclear.
> 
> } However, I think it's a troublesome question whether this is really
> } the right policy to apply.  Unless the directory from which modules are
> } loaded is required to be immutable (flags schg) at boot time, this really
> } does introduce a major security regression: now it is possible to override
> } the whole security policy by placing a new kernel module in the existing
> } directory, when the system is running at securelevel > 0.
> } 
> } I really only see two ways to keep the convenient behavior you and I both
> } seem to want (autoload of modules when filesystems, syscalls, etc. are
> } used) and the safe behavior I and others building (for example) embedded
> } systems with tight security policies want: either we need to rely on
> } the existing securelevel machinery and require that the directory from
> } which autoload occurs is immutable at kernel boot time (elsewise disabling
> } autoload), or we need to use something like veriexec, when we're still at
> } securelevel < 0, to ensure that the modules placed there don't change in
> } any way.
> 
>     I would have to agree.  Having modules loaded at securelevel > 0
> when you can't be absolutely sure of what's in them, completely defeats
> the purpose of running at securelevel > 0.
> 
Strong agreement.

The issue with modules is that they permit user-level operations to change a 
running kernel.  That's true if if a "trusted" directory is used.

I have a friend who runs some server complexes using FreeBSD.  He doesn't 
include bpf in his kernels, to fend off wiretapping attackers.  Sure, they 
could install a custom kernel, but reboots are externally noticeable events.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb