[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: from / to /usr/: a summary

On Mon, 26 Dec 2011, Iustin Pop <iustin@debian.org> wrote:
> > No longer needed.  See /proc/sys/kernel/modules_disabled.
> That's not equivalent - an attacker that can load modules can also
> remove the init script that sets this variable to 1 and reboot the
> machine.

For many of the things that can be done by loading a kernel module an attacker 
can achieve similar goals by replacing libc or by using ptrace to install 
hostile code in a long-running process that runs as root.

Even if booting such a kernel prevented an attacker from hiding files and 
processes (and the other things that a kernel module might do) it still 
wouldn't provide a significant benefit.  It's possible that an attacker might 
get root on your system via a script but lack the knowledge to do anything 
else effective if the script that loads a kernel module fails.

It is a good thing to run with minimum privs, but compiling a new kernel to 
support this seems to be a lot of work for a fairly small benefit.

I can think of one local root exploit that involved triggering a module load, 
one of the possible ways of preventing that exploit would be to disable module 

But it seems to me that a more useful feature would be the ability to create a 
white-list of which modules can be loaded to solve the problem of unwanted 
triggers for module loading and the problem of buggy kernel modules being 
autoloaded in response to something an attacker did.  If we had some module 
management tools that made this easy then it would be a good thing.  For 
example it would be good to be able to white list the currently loaded modules 
(and optionally remove some from the white-list for hardware that is installed 
but never used) and then make a small white-list for the USB devices that are 
suitable for use.

My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply to: