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/
PGP signature
