Question about /dev/mem and /dev/kmem

Question about /dev/mem and /dev/kmem

[Jim Nelson]

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

Re: Question about /dev/mem and /dev/kmem

[Matan Peled]

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

Re: Question about /dev/mem and /dev/kmem

[Arjan van de Ven]

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)

Re: Question about /dev/mem and /dev/kmem

[Wichert Akkerman]

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 <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: Question about /dev/mem and /dev/kmem

[Jim Nelson]

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

Re: Question about /dev/mem and /dev/kmem

[Alan Cox]

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

Re: Question about /dev/mem and /dev/kmem

[Wichert Akkerman]

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 <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.