Re: preventing /dev/kmem and /dev/mem writes?
/dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Strange... I've been booting off raid with grub and it seems to work. What do you mean by 'properly' ? -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
preventing /dev/kmem and /dev/mem writes?
Hi, 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? Cheers, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, 26 Jul 2004 22:54, [EMAIL PROTECTED] wrote: 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. 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). 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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote: /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Hmm. Seems to work here. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, 26 Jul 2004 23:38, [EMAIL PROTECTED] wrote: 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? Yes. But if you can read /dev/mem then you can probably find a copy of /etc/shadow and other useful stuff in there... -- 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]
Re: preventing /dev/kmem and /dev/mem writes?
On Tue, 27 Jul 2004 00:23, Michael Stone [EMAIL PROTECTED] wrote: On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote: /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Hmm. Seems to work here. It seems that lilo code run in real mode puts some special data below 640K, and then the lilo installer which runs from Linux accesses /dev/mem to read it. Whether this information is required depends on which lilo options you use. -- 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]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, Jul 26, 2004 at 10:23:21AM -0400, Michael Stone wrote: On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote: /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Hmm. Seems to work here. Mike Stone This was with a Mylex AcceleRAID 170 RAID 5 with 6 disks. That was when I last tried it 2 years ago. Maybe they have added that capability.. Campbell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, 2004-07-26 at 10:58, [EMAIL PROTECTED] wrote: On Mon, Jul 26, 2004 at 10:23:21AM -0400, Michael Stone wrote: On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote: /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Hmm. Seems to work here. Mike Stone This was with a Mylex AcceleRAID 170 RAID 5 with 6 disks. That was when I last tried it 2 years ago. Maybe they have added that capability.. Umm, yes. Update the Firmware on the Adapter. Then run grub-install /dev/sda Then (if this *IS* a Sarge or Sid machine) run update-grub, answer the questions. Voila. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
