Re: Reliability of RPC services

[Bas Wijnen]

On Wed, Apr 26, 2006 at 10:31:12AM -0600, Christopher Nelson wrote:
> > > You specifically mention ATA and SCSI.
> > 
> > I did not.
> 
> I apologize, someone else must have written that in a message that you
> replied to.

It was mentioned by someone who seemed to know more about busses than I do.
:-)  Appearantly ATA and SCSI have a well-defined protocol on how to handle
devices.  In that case, a bus driver can be used as a proxy to send commands
to the device, without providing access to the other devices on the bus.  Note
that if there is any trusted device on the bus, the bus driver itself must be
trusted.  But that doesn't mean it should only have trusted clients (for the
other devices).

The reason ATA and SCSI were mentioned is that this doesn't work for cardbus
(which I also mentioned).  This is because appearantly cardbus cards can do
their own DMA accesses, which means they can take over the entire system.  In
fact, it means they can do so without being asked, which is a design bug IMO
(it means that I can build a cardbus card which takes over any computer I plug
it in, irrespective of the OS it's running.  Well, unless they cut the power
to the bus, I suppose. :-) ).

> > > I suspect that you may mean something more like having the ability to
> > > mount a custom filesystem on some given device, restrained to a given
> > > range of device blocks.
> > 
> > I do not. I meant being able to send whatever I want to the device itself.
> > I don't know if it needs access to the bus where the device is.  I suspect
> > it only needs to be able to tell to the bus driver what to send to the
> > specified device.
> 
> That depends on whether you want register-level access, or block level
> access.

The idea is to have a bus driver which allows secure access to specific
clients (if they have a capability for it, of course).  Obviously that means
those clients cannot directly send commands on the bus, but only through the
bus driver (which doesn't allow access to other devices on the bus).

> If you want block-level access, then what you want is a custom
> filesystem-like API.  That's all a filesystem is, really, an interface
> to some block device.

Filesystems are just one case which is useful for certain devices (such as a
memory stick).  Others (such as a usb sound card) need other interfaces.  All
this is very well possible with a bus driver acting as a proxy.

> Some devices have a packet interface, but IMHO, that is simply to
> unrestricted to allow.  If you allow any client to construct an ATA packet,
> for example, they can have unrestricted access to any device on the bus.

Of course you don't.  You look at the bus protocol, and see that it has
commands like (this is just made up, I have no knowledge about the ATA bus):
- void move_head (int head, int cylinder, bool is_master);
- char *read_cylinder (bool is_master);
- void write_cylinder (char *data, bool is_master);
- void park (bool is_master);

Now the bus driver simply exports those functions to the clients, but without
the is_master argument.  That is filled in by looking at which capability they
used to make the call.  So if you have the slave capability, you cannot send
commands to the master.

> Putting a packet filter in place might help that, but it adds complexity
> that is pointless.

Clients don't create packets.  They give commands, and they are turned into
packets by the bus driver.

> > e.g. if I can hotplug my own SCSI disk, I don't need to deal 
> > myself with the SCSI bus. All I need is the bus sending 
> > whatever I tell it to, but only to my device.
> > 
> > Maybe it's already to much, given the design of SCSI, IDE or 
> > USB bus, I've no knowledge of that part.
> 
> I agree that there should be a way to give users open access to hotplug
> devices like USB, etc, but on the other hand, what if your OS boots off
> of a USB flash device?

Then you should better make sure that the capability for that usb device is
not given to the user as part of the terminal he logs in on.  No problem
there.

> There are certainly ways to do what you propose, but they add a needless
> layer of complexity.  It would be better to use a higher level of
> permission, perhaps like mount points,

Eek, that sounds like Linux!  The cool thing about the Hurd is that if you
have access to a device, you are allowed to use a filesystem driver on it.
This is a major problem with Linux IMO: if I have access to /dev/sda, so I can
actually read and write every byte on the device, and I know it contains 2
partitions, one of which is ext2, then I am still not allowed to simply use cp
and mv and ls and redirection and all other things I'm used to, just because
the kernel can't handle it.

In contrast, the Hurd allows you to do whatever you want with it (also the
current version on Mach).  This is one property we definitely don't want to
lose.

> that would let a user read and write data on hot plug devices that get
> plugged in during their session.

Actually, any device that is part of the terminal should be accessible, no
matter when it was plugged in.  It is the system administrator's job to make a
proper list of devices and give capabilities to them to the login manager
(which can then give them to the logging in user, revoking them again when the
user logs out).

> But this completely open access to the bus and/or device registers breaks
> security confinement in a fundamental way.

Built-in busses are likely owned by the system (however, they don't need to be
if all possible devices on it would be owned by the logged-in user anyway).
However, it is also possible to add extra busses to the system.  An usb hub
sort of does that.  Also, there are for example parallel ports which plug into
a usb bus.  If the user owns the usb slot where such a device is plugged in,
then he should own the full device, including access to all busses and/or
registers in it.

But of course any bus which (indirectly or directly) has a trusted system
device on it, such as the main hard disk, must not be given away as part of
the terminal session.

> > BTW: your MUA is broken, adding some illegal headers about 
> > threads but not the standards one, thus breaking threads, at 
> > least in my MUA, which is not very comfortable in such 
> > ramified discussions...
> 
> I use Outlook, sorry.

Huh?  I thought you cared about security.... *confused*

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