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:
http://www.wiggy.net/debian/developer-securing/
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.
Cheers
> --
> 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: