> Think about this: there are situations where root *MUST* be subject to
> various restrictions (via capabilities, immutable files, etc). If root is
> able to talk directly to the hardware, these restrictions become
> unenforcable - security just went out of the window. This is unacceptable:
> Linux must not do it. (Or rather, it must be possible to prevent Linux
> doing it.)
Root can only talk directly to the hardware when given appropriate
capabilities - CAP_RAW_IO I believe.
If anything Andre should just be looking at adding that capability to
the accesses which allow you to destroy things - because those same
ioctls potentially serve useful purposes (yes, one day you will want
to upgrade your drive firmware without running DOS/Win - I already
don't have DOS/Win on any of my computers or laptops, the closest I
have to it is a small portion microcode from the Hollywood Plus driver
extracted to use with the Linux driver for that card...).
And believe it or not, on a laptop which is only ever used behind a
company firewall or when dialed up over a rather securely filtered
dial-up, the chances of someone locating it on a dynamic IP and
hacking root given no access to any open ports are somewhat more
remote than the chance of the drive vendor developing a firmware
upgrade tool for Linux, given appropriate interfaces.
Remember, as long as root can insert a module root can re-write the
kernel security model from the inside... and as soon as root can't
insert a module you've removed popular functionality. (Personally I
don't use modules but honestly - the vast majority do and probably
always will.)
David.
-- ---------------------------------------------- David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax: +61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.au NASDAQ: PCNTF << fast 'n easy >> ----------------------------------------------- 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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:17 EST