Re: Reliability of RPC services

[Bas Wijnen]

On Thu, Apr 27, 2006 at 08:51:26AM -0600, Christopher Nelson wrote:
> > 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 haven't, but it isn't what this is about.  I have written usb drivers for
Linux using libusb (so they should also work on some other systems, but I
didn't test).  From that experience I can tell you that it is very well
possible to set up an interface which allows users to control their USB device
without any effect (except bus bandwidth consumption) on other devices.  In
fact, what we want is already possible in Linux:
When I plug in a usb device, a node pops up in /dev/bus/usb/nnn/mmm.  Suppose
I have access to this node.  Then I am allowed to write a driver which uses
this device (through read and write and ioctl, usually).

So far so good.  If I have a strange device, such as the spectrometer I wrote
a driver for, and I have access to the device node, then I can use my driver
and measure spectra with it, using a program written by me specifically to
communicate with that driver.

However, what happens if I have a printer which happens to be unknown to the
system administrator?  Assume I still have access to the node, so I can write
a driver for it.  But now I want to print a webpage from firefox.  Firefox
asks the driver framework for a list of printers to present to the user (or it
asks the shell to do this, I suppose).  Now I want my printer to be in that
list.  Which means it must be registered with the driver framework (or there
must be a parallel list of my personal drivers, but that seems wasteful, and
_all_ instances of programs looking for drivers must be changed to look in
this list as well, which doesn't seem feasable, but I may be wrong about
that).

The point is, given that I have the right to write a driver for a device, I
should be able to use that right to get me a driver which is equivalent to a
system-provided one.  For really special devices that doesn't matter.  For
devices in a certain class (storage, network, printer, etc) the system has to
allow this explicitly to make it work.

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

Anyone who has a capability to the interface (usually the bus driver) can use
that and provide his own driver.  The other step is to register that driver in
the list of known drivers for that class, so it can actually be used.

My guess is that the usb bus driver itself may be user-provided as well, if
there are no devices on the bus which the user shouldn't have access to.
However, that is just a guess and quite irrelevant for the purpose of this
discussion.  This is about letting the user provide drivers for device which
do have a safe interface.  If the usb bus is not one of them, then the bus
driver must be provided by the system.  If it is, then it can potentially be
user-provided without security problems.

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

Perhaps yours doesn't, but they exist.  The point is that in the situation at
hand (an unchecked user may plug something into our network, thereby doing
damage to our network), the OS isn't actually failing security-wise.  The OS
protects everything it has authority over, and it succeeds in that.  The
system is not compromised.  If people are capable of plugging their own
devices into the network cable, and that can do damage to the system, then
that is a different problem.  It can be solved in several ways (mechanically
blocking access to the cable, using an encrypted link with a key that is not
accessible for the user, ...), but the fact that the user can use his own usb
device is not the problem.  The user can use it anyway if he provides a system
with a usb bus.

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

This assumption sounds like a very weak security-practice.  Especially because
there are real solutions, this is not something to count on.

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

This is not the point.  The point is that the system administrator is on
vacation, and the management doesn't consider this thing important enough to
call him back, and I want to use my device anyway.  And, and this is
important, my device can only hurt myself if it blows things up (except if it
does that literally. :-) ), so the system administrator shouldn't have any
problem at all with it (except if he wants to make life harder for the user,
which may be usual in practice, but I don't want to assume that.  He wouldn't
use the Hurd in that case anyway ;-) ).

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

Say I have a encryption smartcard.  Since those things aren't very usual
(yet), I should bring my own cardreader with it to make sure I can actually
use it.  I would very much like to be able to use it without asking the system
administrator permission (mostly because of the delay, but also because it's
none of his business).

An other case: I have a Yopy PDA, which can be connected to a usb master (it
is a usb slave itself) via the usbnet protocol.  I want to be able to set up a
network connection to it without asking the system administrator.

In general, any device which is so obscure that the system administrator
doesn't know about it, which plugs into a safe bus (that's mostly usb, I
suppose, and possibly firewire).

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

It is less secure indeed, but not for this reason.  Whether the drivers are
trusted or not, they will not have more capabilities than they need, so they
cannot be used to take over the whole system (unless they could anyway, for
example they do DMA).

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

Not at all.  No security checks are involved.  Anyone who has the capability
to the bus is allowed to use it.  No checking is performed.  The difference
between our models is that we want to give those capabilities to the user, and
you don't.

> As complexity increases, confidence in it's security decreases.

The reason that needing a system administrator for every driver decreases
security is that people will get used to "being" system administrator all the
time (as is usual on Windows, and on some distributions of GNU/Linux), because
they "need the permissions all the time anyway".  This is about single-user
machines, obviously.  On multi-user machines it's annoying for the user and
extra work for the system administrator.  Both are to be avoided IMO.

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

That is a good idea, and I wouldn't want to complicate matters.  I don't think
I do, though. :-)

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

There is no separate security layer.  The difference is who gets his hands on
the capabilities.

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

That's why drivers for such devices are not planned to be user-provided by
anyone.  User-provided drivers should only be allowed for safe busses, so they
cannot anyone except users of the driver itself.  And programs shouldn't
accidentily use that driver: that is, if you install a network driver, then it
shouldn't be used by my programs unless I explicitly tell them to use it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature