RE: Reliability of RPC services

[Christopher Nelson]

> > Now, the chipset will emulate an ATA bus, but you can also drive it 
> > straight from the PCI bus.  The same is true with the video 
> card: you 
> > may access the legacy VGA registers, or map the PCI into memory and 
> > drive it that way.  The point is that the "bus driver" 
> would have to 
> > be absolutely specific to that chipset.  A generic PCI 
> driver (which 
> > works quite well with the i80810) wouldn't know what the heck was 
> > going on, so it would allow someone to both map the PCI drive 
> > controller, and also the "legacy" ATA interface.  It could not 
> > conceivably protect the devices because it does not know 
> enough to do 
> > so.  In other words, it puts a huge burden on driver developers 
> > because they then have to worry about a security framework 
> as well as 
> > a stable hardware/software interface.
> 
> This is quite irrelevant, I think, because it is still about 
> the PCI bus.
> The ATA bus and the VGA controller are both PCI devices, and 
> therefore cannot be driven with untrusted drivers.  However, 
> an ATA device could, for example, because (if I understood it 
> correctly) the ATA protocol simply doesn't allow such 
> "cheating" as you describe above.  It's very clear when a DMA 
> is performed, for example.

No.  VGA is not PCI.  It is legacy.  So is ATA.  There are register sets
used to program them.  They have absolutely nothing to do with PCI.
They sit in the processor I/O space and are accessed (on x86 machines)
with the in and out instructions.  

You can *also* access some ATA chipsets and video cards through a PCI
interface.  My point here is that there are TWO interfaces to the same
hardware systems.  There may be more for other hardware systems.  Your
device driver security subsystem needs to know what paths are aliases
for the same devices.  This is very hard because it then needs to know
what register sets can be used to program what devices, in addition to
what paths you may be able to take to them in PCI space.  So not only
does it need to be authoritative over a given bus (PCI) it also needs to
be authoritative over a given set of I/O registers in processor I/O
space.  They are SEPARATE and DISTINCT from the standpoint of software
programming.  
 
> > IMHO, security is not the domain of drivers.  It is the 
> domain of the 
> > kernel together with software that is designed for that purpose.  
> > Other layers in the system should worry about security.
> 
> Security is arranged through capabilities.  If some 
> interfaces are fragile, and abuse cannot be prevented, then 
> care must be taken that no capability to it ends up in 
> untrusted hands.  However, if interfaces can handle abuse 
> (that is, no problems remain after revoking the capability 
> and perhaps some cleanup such as resetting the bus), then it 
> is fine to give capabilities to it to the untrusted parties.  
> Of course the capabilities should still not be given to the 
> wrong program, but it makes sense to give them to the session 
> of the user who logs in.

The problem here is that you are saying we have these great big vault
doors that you can't break down, and I am saying yes, but two of the
doors lead into the same place, and everyone is only watching one of
them.  So while everyone is fixated on Door A, I just walked in through
Door B (because no one was watching it) and took all of your money.
 
> > While I completely agree that there should be some facility to give 
> > users access to devices, especially hotplug devices, 
> without having to 
> > be root or have root give them access, I do not feel that 
> the driver 
> > level is the place to do it.
> 
> Of course it is.  How else can I use my brand-new 
> totally-unknown-to-my-system-administrator device?  If it 
> doesn't plug into a "dangerous" bus (such as cardbus, 
> unfortunately), but into something which can be kept in 
> control, such as usb, then there's no reason to deny me the 
> ability to provide my own driver.

You can't, obviously.  As system administrators, we don't want random
people hooking their junk up to the computer.  It's not THEIR computer,
so they don't get to decide what they can hook up to it, anyway.  

There are plenty of reasons why I want to deny you access to a so-called
"safe" bus.  For example, I don't want you hooking up a USB network card
to a computer, and potentially doing something malicious to the network
with your device.  I don't want you to hook up a camera or a scanner
that you can use to steal sensitive documents.  There are a lot of
things I may not want you to do with a system that you use but DO NOT
own.  If you can install a random driver, I cannot prevent those things
because I do not know where on the USB device they may show up, and I do
not know all the possible ID's of all the possible hardware that I
forbid on my systems.  Therefore, it is imposssible for me to fabricate
a set of policies that permit or deny and given device.

-={C}=-