Re: Reliability of RPC services

[Jesse D. McDonald]

On Wednesday 26 April 2006 18:07, Christopher Nelson wrote:
> 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?

This appears to be the primary point of contention for at least one version of 
this thread, but the resolution is simple. In no case would an untrusted 
device driver loaded by the user be granted free access to either the PCI bus 
(or any device thereon, given their DMA capabilities) or the system I/O 
space. There is no aliasing problem, because the trusted driver *doesn't* 
need to know about all the possible aliases (at least in this case or for the 
stated reason). There is no case where a user-loaded program (possibly 
a "device driver", which is just a type of program) could access those 
insecure legacy ports without going through a trusted server. However, in 
limited cases, where it is well known that there is no danger (such as in the 
case of the USB bus) a trusted system bus controller may grant access to a 
specific unused device to an untrusted user-loaded program.

> > 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.

I agree. However, the proposed model does not depend on the users taking any 
kind of responsibility for the security or correct operation of the system. 
It is the bus controllers (necessarily trusted software components) that are 
responsible for ensuring the security of the system.

> > So you say there is a case when you do not want users to
> > connect devices. Fine. 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 option 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.

System administrators will doubtless have the ability to instruct their bus 
drivers to withhold access capabilities from untrusted processes. However, 
while there are certainly places where such measures are worthwhile, I 
believe that those cases are extremely limited. In most situations where it 
would be possible to connect a user-provided device, physical security would 
naturally be a far greater issue. In the network case, for example, you were 
worrying about someone connecting a USB adapter between your network and the 
locked-down PC, while it would be far easier to simply circumvent the PC's 
software entirely with a small network-capable PDA. If you can connect a 
rogue USB network adapter you can connect any other small network device just 
as easily.

> 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.

The whole point was to allow people to use devices *without* administrative 
priviledges, so that isn't really a solution. In any event, you can't get 
away from requiring at least some security-conscious device drivers. A system 
where all device drivers must be considered trusted is actually *less* 
secure, since a flaw in any device driver can potentially be used be 
untrusted programs to gain control over the entire system. The proposed model 
limits such potential weak points to the bus drivers themselves (including 
e.g. PCI drivers which can become bus controllers). The remaining device 
drivers need only be a trusted as the clients that depend on them -- which is 
one of the fundamental reasons for using a microkernel in the first place.

pgpkHOcxFWDhg.pgp
Description: PGP signature