> So, would it be feasible to make it possible to disable direct hardware
> access (/dev/mem, /dev/nvram, HD ioctls, what else?) completely in kernel
> config?
Grrr. It's doable from userspace. Just echo appropriate number in
/proc/sys/kernel/cap-bound in /sbin/init (or early in rc.S) and that's all.
> Or are some of those always needed? If not, then they could be
> disabled (do not enable what you don't need, as with /etc/inetd) on a
> trivial web server box, route, firewall etc.
You CAN disable it all with one small keystroke.
> Of course, kernel module loading should be disabled as well (or made
> available only via challange-response authentication or something (*)).
You can load all needed modules and then disable modules loading with the
same /proc/sys/kernel/cap-bound ...
> Make your boot media read-only, and the cracker shouldn't be able to
> change the kernel either.
> Which applications need (dangerous) direct hardware access?
XFree86
> In which cases would it be possible to disable it?
When you do not need GUI :-)
> You can't propably shield your monitor if you want to run X, but for server
> boxes, that's not a big deal.
Exacttly. And for such protection you DO NOT NEED Andre's patch. You need
MUCH smaller and clearer Vojtech's patch (just two lines instead of 60K).
> If nothing else, people running honey pot boxes to attract crackers would
> propably want to use this.
> Or is this a completely dead idea?
It's not dead idea. Even more: such protection ALREADY is offered by kernel.
> (*) Publib key in kernel, private key held separately by the
> administrator. Without writable /dev/mem (etc) this should work?
No, this is not implemented (yet?). You can load all needed modules early in
boot process and then disable everything non-needed (including ability to
load modules).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/