Re: from / to /usr/: a summary
* Russell Coker <russell@coker.com.au> [111226 14:16]:
> 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.
Except replacing libc does not help against static binaries and here are
well known ways to disallow ptrace.
> 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.
Not being able to hide files and being able to notice file modifications
is no benefit?
> 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.
First of all it is quite a significant benefit. And you get quite some
other advantages like being able to boot faster and needing less memory,
both RAM and on disc.
> 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.
Feel free to implement this. But please stop telling people that what
they do should not be supported just because you would do it differently
or there might be some better vapourware solution.
Reply to: