> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
