I was looking at some articles about rootkits on monolithic kernels, and had a
thought. Would a kernel config option to disable write access to /dev/mem and
/dev/kmem be a workable idea?
I know it'll kill X (unless you're using the framebuffer X server), but would
there be any other big problems? SELinux has a finer-grained control over those
files, but also involves a bit of administrative and system overhead.
I see this as an option that could be used in routers, web servers, firewalls and
other systems that have a greater risk of exposure to rootkits. Granted, it only
makes sense with a monolithic kernel, but most people nowadays would only use
monolithic kernels for security reasons. You could also put a couple of
printk()'s in to raise alarms if someone does try to open the device file for writing.
Am I speaking ex rectum? Granted, I'm kinda new to this, but I can't see any
reason not to offer the choice to someone compiling a kernel - and I think it
could be done with a minimum of code bloat.
I offer this to the firing range ;)
Jim
Jim Nelson wrote:
> I was looking at some articles about rootkits on monolithic kernels,
and had a thought. Would a kernel config option to disable write >
access to /dev/mem and /dev/kmem be a workable idea?
Yes, its a workable idea, and in fact, has already been implemented in
grsecurity.
http://www.grsecurity.net/features.php
On Sun, 2004-11-28 at 22:57 -0500, Jim Nelson wrote:
> I was looking at some articles about rootkits on monolithic kernels, and had a
> thought. Would a kernel config option to disable write access to /dev/mem and
> /dev/kmem be a workable idea?
look at the -mm patch series ;-)
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/dev-mem-restriction-patch.patch
(fwiw this patch is also in the Fedora Core kernels for quite some time
now)
Previously Jim Nelson wrote:
> I was looking at some articles about rootkits on monolithic kernels, and
> had a thought. Would a kernel config option to disable write access to
> /dev/mem and /dev/kmem be a workable idea?
Yes, but not a very useful one since it is an incomplete solution. You
can easily do something better using /proc/kernel/cap-bound (like
writing 0xFFFCFFFF into it).
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
> Previously Jim Nelson wrote:
>
>>I was looking at some articles about rootkits on monolithic kernels, and
>>had a thought. Would a kernel config option to disable write access to
>>/dev/mem and /dev/kmem be a workable idea?
>
>
> Yes, but not a very useful one since it is an incomplete solution. You
> can easily do something better using /proc/kernel/cap-bound
Isn't that /proc/sys/kernel/cap-bound?
> (like writing 0xFFFCFFFF into it).
>
And what stops an attacker who's already gained root from doing a "cat "0" >
/proc/sys/kernel/cap-bound" ?
> Wichert.
>
Previously Jim Nelson wrote:
> Isn't that /proc/sys/kernel/cap-bound?
yes, it is.
> And what stops an attacker who's already gained root from doing a "cat "0"
> > /proc/sys/kernel/cap-bound" ?
The fact that you are not allowed to change the cap-bound settings with
that specific bitmask.
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
On Llu, 2004-11-29 at 10:47, Jim Nelson wrote:
> And what stops an attacker who's already gained root from doing a "cat "0" >
> /proc/sys/kernel/cap-bound" ?
If they already had root you've already lost.
An SELinux policy would probably be a lot more useful because you also
want to block ioperm/iopl