What IS the solution?
There isn't one, don't let root run untrusted code on your box
wherever possible is as best as you can do.
If the drivers can be done in the userspace then the damage can
be done in the userspace (assuming the hardware can be damaged).
Yes, as has been true for many years.
I assume that root-level userspace comprimise is possible
(statistics show that it happens too often to ignore it - like it
or not). So the kernel should protect all hardware form being
damaged.
We can restrict these ioctls and direct access to i/o ports with
capabilities.
Except you will probably still allow me to write to /boot/vmlinuz or
equivalent, so I write a virus which patches your kernel. Next time
you reboot, boom -- dead HD or whatever.
So the only 'bulletproof' way is to do all hardare access in
kernel and not provide userspace _any_ methods for doing it
directly. This means all zip drivers & graphics drivers & so on
in the kernel :-(
This is just silly, that doesn't buy anything.
This whole thread (or ten) is just getting ridiculous. Bad hardware
exists, if root wants to trash it, and they have sufficient clue,
they can -- and nothing reasonable you can do will prevent this, not
under a unix-like OS anyhow.
--cw
-
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:20 EST