Messages in this thread | | | Date | Mon, 24 Jul 2000 06:54:47 +1200 | From | Chris Wedgwood <> | Subject | Re: What's wrong with IDE patch and what proper solution should be... |
| |
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/
| |