RE: Reliability of RPC services

[Christopher Nelson]

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

This is a good point.

>However, 
> in limited cases, where it is well known that there is no 
> danger (such as in the case of the USB bus) 

I have never written a USB stack.  Has anyone involved in this
conversation ever done so?  I've read the docs and I have a reasonable
understanding of the interface, but before someone goes around saying
that it's well-known to be secure and totally possible, it would be a
good idea to sit down and actually work out a design and prototype
implementation.  As far as I'm aware, no one has ever done this, or
tried to do this, so I certainly don't think that anyone can say it's
"well known."  It may be commonly theorized, but that's a different
story altogether.
 
> > > 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.

Sure, but my PDA simply doesn't have the bandwidth and/or processing
power to do serious damage.  It might be able to cause some damage, but
not to the same degree as a computer system with a processor an order of
magnitude faster, and dedicated signal processing hardware.

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

I can see that there are cases where you might want to allow known okay
devices connect without authorization.  In essences, those devices would
be pre-authorized.  For example, USB Mass Storage interface.  That's a
well-known, common interface.  Please present me with a practical usage
scenario that requires your model.  

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

I don't see how your model increases security.  You still have to have
"trusted" drivers.  You still can have a bug in them, and it can still
be used.  Your model allows for user drivers in *very specific cases*.
You are additionally complicating their code with a lot of security
checks.  As complexity increases, confidence in it's security decreases.
That's one of the reasons that Shap et al. want to make Coyotos servers
extremely simple, and to keep them single threaded where at all
possible.

How does having a separate security layer, whose only purpose is to
provide security and filtering, make the system less secure?

> The proposed model limits such potential weak points to the 
> bus drivers themselves (including e.g. PCI drivers which can 
> become bus controllers). 

This is simply untrue.  Any driver which has access to a piece of
hardware that accesses physical memory cannot be limited to it's own
address space.  Therefore, bugs in any driver that may use DMA or (for
example, a video card that reads and writes to memory) can propagate
outside it's process boundary.  A microkernel does not and cannot stop
such propagation errors.

-={C}=-