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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
