Re: Reliability of RPC services

[Michal Suchanek]

On 4/26/06, Christopher Nelson <address@hidden> wrote:
> > > Now, the chipset will emulate an ATA bus, but you can also drive it
> > > straight from the PCI bus.  The same is true with the video
> > card: you
> > > may access the legacy VGA registers, or map the PCI into memory and
> > > drive it that way.  The point is that the "bus driver"
> > would have to
> > > be absolutely specific to that chipset.  A generic PCI
> > driver (which
> > > works quite well with the i80810) wouldn't know what the heck was
> > > going on, so it would allow someone to both map the PCI drive
> > > controller, and also the "legacy" ATA interface.  It could not
> > > conceivably protect the devices because it does not know
> > enough to do
> > > so.  In other words, it puts a huge burden on driver developers
> > > because they then have to worry about a security framework
> > as well as
> > > a stable hardware/software interface.
> >
> > This is quite irrelevant, I think, because it is still about
> > the PCI bus.
> > The ATA bus and the VGA controller are both PCI devices, and
> > therefore cannot be driven with untrusted drivers.  However,
> > an ATA device could, for example, because (if I understood it
> > correctly) the ATA protocol simply doesn't allow such
> > "cheating" as you describe above.  It's very clear when a DMA
> > is performed, for example.
>
> No.  VGA is not PCI.  It is legacy.  So is ATA.  There are register sets
> used to program them.  They have absolutely nothing to do with PCI.
> They sit in the processor I/O space and are accessed (on x86 machines)
> with the in and out instructions.
>
> You can *also* access some ATA chipsets and video cards through a PCI
> interface.  My point here is that there are TWO interfaces to the same
> hardware systems.  There may be more for other hardware systems.  Your
> device driver security subsystem needs to know what paths are aliases
> for the same devices.  This is very hard because it then needs to know
> what register sets can be used to program what devices, in addition to
> what paths you may be able to take to them in PCI space.  So not only
> does it need to be authoritative over a given bus (PCI) it also needs to
> be authoritative over a given set of I/O registers in processor I/O
> space.  They are SEPARATE and DISTINCT from the standpoint of software
> programming.

And what? It is the job of the pci driver to also claim (or disable)
the legacy io ports. The PCI bus or io space cannot be given away so
it causes no additional problem that some devices live in several
places in there.


>
> > > IMHO, security is not the domain of drivers.  It is the
> > domain of the
> > > kernel together with software that is designed for that purpose.
> > > Other layers in the system should worry about security.
> >
> > Security is arranged through capabilities.  If some
> > interfaces are fragile, and abuse cannot be prevented, then
> > care must be taken that no capability to it ends up in
> > untrusted hands.  However, if interfaces can handle abuse
> > (that is, no problems remain after revoking the capability
> > and perhaps some cleanup such as resetting the bus), then it
> > is fine to give capabilities to it to the untrusted parties.
> > Of course the capabilities should still not be given to the
> > wrong program, but it makes sense to give them to the session
> > of the user who logs in.
>
> The problem here is that you are saying we have these great big vault
> doors that you can't break down, and I am saying yes, but two of the
> doors lead into the same place, and everyone is only watching one of
> them.  So while everyone is fixated on Door A, I just walked in through
> Door B (because no one was watching it) and took all of your money.

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.

>
> > > While I completely agree that there should be some facility to give
> > > users access to devices, especially hotplug devices,
> > without having to
> > > be root or have root give them access, I do not feel that
> > the driver
> > > level is the place to do it.
> >
> > Of course it is.  How else can I use my brand-new
> > totally-unknown-to-my-system-administrator device?  If it
> > doesn't plug into a "dangerous" bus (such as cardbus,
> > unfortunately), but into something which can be kept in
> > control, such as usb, then there's no reason to deny me the
> > ability to provide my own driver.
>
> You can't, obviously.  As system administrators, we don't want random
> people hooking their junk up to the computer.  It's not THEIR computer,
> so they don't get to decide what they can hook up to it, anyway.
>
> There are plenty of reasons why I want to deny you access to a so-called
> "safe" bus.  For example, I don't want you hooking up a USB network card
> to a computer, and potentially doing something malicious to the network
> with your device.  I don't want you to hook up a camera or a scanner
> that you can use to steal sensitive documents.  There are a lot of
> things I may not want you to do with a system that you use but DO NOT
> own.  If you can install a random driver, I cannot prevent those things
> because I do not know where on the USB device they may show up, and I do
> not know all the possible ID's of all the possible hardware that I
> forbid on my systems.  Therefore, it is imposssible for me to fabricate
> a set of policies that permit or deny and given device.

So you say there is a case when you do not want users to connect devices. Fine.
And 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 optoin should be removed for everybody.

Thanks

Michal