But we're talking about root getting access to a machine that's already
been booted, with all drivers loaded, and no capability to load modules
or reboot. Good point though.
>
> > a reboot with a new kernel or at least a module to be loaded. Even root
> > can only get certain permissions by either loading modules (which get
> > priv mode in the chip) or by using device files for access to existing
> > drivers. Or I could still be talking rubbish. Couldn't
> > /dev/{mem|kmem|kcore} be hardwired to prevent BIOS flashing ?
> >
> > It's easy to prevent modules being loaded: don't compile the kernel with
> > support. It's also easy to prevent rebooting with a new kernel...
> >
>
> Sure, you can start disabling all those "pesky features" that may be
> misused by root... Let's see, you would need to disable the above /dev/
> files, the proc FS, raw access to block devices (to really prevent booting
> with a new kernel), module loading (as you said), the ioperm syscall...
> did I miss anything? In the end, the resulting system will lose a lot of
> functionality (i.e. no Xserver or even fsck).
You're exaggerating here, though I get your point. We don't disable the
above devices, we protect them. We don't lose raw access to block
devices, because the BIOS can prevent a reboot (BIOS password anyone
??). We do lose module loading, sure, but we just have to patch
ioperm(). fsck will be fine. iopl() on the other hand would cause some
serious heartache so X would be rather tricky. But that's okay if we're
thinking server rather than workstation.
I'm not really advocating this (I think that your suggestion of using an
EPROM i.e. NOT an EEPROM would be a much better idea!) but rather just
trying to see if it's even possible for those people who are unable or
unwilling to muck about with the motherboard.
:-)
Neil
-
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/