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
loading.
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: