Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 6 Mar 2011 16:14:58 -0500
From: Steve Grubb <>
Cc: Vasiliy Kulikov <>
Subject: Re: kernel: modules_disabled policy

On Saturday, March 05, 2011 11:16:43 am Vasiliy Kulikov wrote:
> Is it possible to implement strict do-not-touch-the-kernel policy for
> root via disabling LKM loading and _all_ other indirect places with write
> access that allows root to do something, but being too relaxed and
> allows to write to [almost] arbitrary kernel location?  This would make
> root the Boss Of Userland, but as to the kernel it would be but just a
> privileged client.  Or such policy would be incomplete and there is
> almost always a way to by-pass it due to the system design?

There's been some discussion on this here:

As root, you could modify /etc/modprobe.d/  and add your root kit and issue a system 
reboot. That might get attention, but its possible to load modules by rebooting. Along 
the same lines, you could regenerate the initramfs with your module being loaded 

What was proposed was another kind of deployment module where the initramfs and kernel 
is on readonly media so any kernel updates have no effect. The initramfs has all the 
kernel modules that wil ever be loaded and anything that manages to live in 
/lib/modules will not be used for anything. Since root is in control of user space, he 
could change any program that the kernel calls out to load modules. So in the 
initramfs we want to drop 2 capabilities so that all kernel helpers are not able to 

There are lots of loose ends. I think you found another place where root in the 
traditional sense was perfectly fine doing a snapshot. But if you want to allow anyone 
to have root, but not be able to get arbitrary code running at ring0, there will be 
quite a bit of looking for these uncontrolled places and getting them under some 
capability check that can be excluded without diminishing roots abilities too much.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.