[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kernel module loading vs securelevel
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.
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
Main Index |
Thread Index |