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

Re: preventing /dev/kmem and /dev/mem writes?

> > I have a machine that has been the unfortunate victime of SuckIT
> > r00tkit. As this exploit relies on writing to /dev/kmem, I was thinking
> > of making /dev/mem and /dev/kmem unwriteable. I have heard this breaks X
> > and some gdb functions, but does anyone know any other specific problems
> > this might have?
> Some boot loaders need to access /dev/mem or /dev/kmem for getting BIOS data.  
> Once your machine is in a bootable state you should not need /dev/k?mem for 
> that.

but isn't that just read-only? 

Another method I saw was this:


which says you can 'remove CAP_SYS_MODULE and CAP_SYS_RAWIO from the
global set of allowed capabilities' which the author says will make
/dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as
it doesn't support booting off RAID devices properly)

> klogd uses such access, probably for decoding Oops messages (it can probably 
> operate fine without it for some loss of functionality).
> vmware uses such access (and lots of other invasive access to kernel memory).

I don't use it

> Many xdm type programs read kernel memory as a source of randomness.  This is 
> bad because kernel memory is not random and it may leak some information from 
> the kernel.  xdm in Fedora should be fixed to use /dev/random.

It is a server, so not a problem for this

> The X server needs such access if it's accessing the hardware directly.  If it 
> uses the fbdev then it should not need such access.
> The above is taken from the SE Linux policy.  Apart from the programs listed 
> above in SE Linux nothing is granted such access.


> -- 
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page

Reply to: