RE: Reliability of RPC services

[Christopher Nelson]

> > 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.
> 
> And what? It is the job of the pci driver to also claim (or 
> disable) the legacy io ports. The PCI bus or io space cannot 
> be given away so it causes no additional problem that some 
> devices live in several places in there.

This is my point.  The PCI driver may not KNOW about all the legacy
ports.  And why should it need to?  Does it need to know about every
legacy port for every ISA device ever made?

> > 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.
> 
> This only applies to the already insecure PCI bus and io 
> space. And possibly some multipath storage controllers. The 
> earlier are non-issue because you cannot grant access to them 
> anyway. When using the later you must know what you are 
> doing. And it is the responsibility of the user who connects 
> and uses such device.

My point exactly.  You cannot depend on users to take responsibilty.  A
malicious user, especially.
 
> > 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.
> 
> So you say there is a case when you do not want users to 
> connect devices. Fine.
> And does that mean that nobody would ever want users to 
> connect devices? In my book it does not.
> Making it possible to connect devices does not remove the 
> choice to forbid connecting them. But because you do not want 
> users to connect devices does not mean that optoin should be 
> removed for everybody.

If it is a case of all or nothing, then nothing.  This may be a
situation where you could have a system global "allow user drivers"
setting.  

Regardless, if you have your own computer, I don't see why this matters.
You have ultimate authority, so there could be some mechanism that
notices that a new device has been plugged in, asks you to authenticate
as administrator, and then goes about giving you access.  This mechanism
doesn't require security at a driver level.

-={C}=-