On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > Thanks for the input. Two points: > > 1. I coming at this problem as a laptop user so pcmcia modules must remain > and be loadable and unloadable at will - as far as I know, there is no > direct > way to compile pcmcia modules directly into the kernel like the other > drivers. your stuck then live with the risk of knark, nothing you can do about it but install security updates and be a vigilant admin unlike all the morons with root passwords. > 2. What if /dev/mem access was determined at kernel compile time as an > option? no > I'm not familiar with lcap, but I assume it disables access to /dev/mem > without > breaking anything, so why not make this risky access optional at kernel > level? access to /dev/mem, /dev/kmem, /proc/kcore and such require a capability (privilege) known as CAP_SYS_RAWIO, its not just file permissions or having uid=0. lcap removes CAP_SYS_RAWIO from the capability bounding set, which means that NO process already running or run in the future can hold that capability, without the capability the kernel denies any read or writes to these devices, even to root. as for not breaking anything, that depends, nothing breaks on my firewall which is headless and runs only a handful of processes. the only thing out of the ordinary is a warning from klogd about not being able to read /dev/kmem for whatever reason it wants to poke there, it still works. if you use X though you will be disappointed, X mucks around /dev/mem. > Concurred, however, I prefer proactive rather than reactive. The danger of > undisclosed exploits always leaves this area of doubt. If the expoilt cannot > happen in the first place, a whole generation of exploits is eliminated at > once. in this case you must make very large sacrifices to accomplish this. including giving up kernel modules and X11. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgppKlGoK8Gns.pgp
Description: PGP signature