In <E13GQYN-0004XZ-00@roos.tartu-labor> Meelis Roos (mroos@linux.ee) wrote:
PBD>> Right now, you can write (for example) an Iomega Jaz utility without
PBD>> any kernel futzing at all. Contrast this with Windows where it seems
PBD>> necessary to always install a new driver.
> What IS the solution?
> If the drivers can be done in the userspace then the damage can be done in
> the userspace (assuming the hardware can be damaged).
> 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.
What for ? On 99% systems (if not 99.999% system - all system with CAP_SYS_RAW
in system OR with boot device accessible for write for root) out there
malicious root CAN change RUNNING kernel as much as he(she) want or can
insert dmage code in bootsector to destroy your drive on next boot.
> We can restrict these ioctls and direct access to i/o ports with capabilities.
See above.
> OTOH:
> * We want to use some mapped memory & ports (xfree)
> Solution exists as a memory and port range enabler
> So the side channel (doing direct io) can be closed for unnecessary
> access.
> * We want to use raw ide & scsi & etc commands. This is a problem.
> Is a general safe filter even possible (such that cd writing, zip dives
> etc continue to work)? I assume this is not possible.
> 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 :-(
> Therefore:
> _IF_ the hardware can be damaged THEN no userspace application must be able to
> access it directly and to use such devices, a kernel level driver must exist to
> provide all the access safely.
> Or am I missing something?
You missed small yet imortant fact shown above.
-
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 : Mon Jul 31 2000 - 21:00:16 EST