[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Jesse D. McDonald |
Subject: |
Re: Reliability of RPC services |
Date: |
Wed, 26 Apr 2006 19:05:32 -0500 |
User-agent: |
KMail/1.9.1 |
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. There is no aliasing problem, because the trusted driver *doesn't*
need to know about all the possible aliases (at least in this case or for the
stated reason). There is no case where a user-loaded program (possibly
a "device driver", which is just a type of program) could access those
insecure legacy ports without going through a trusted server. However, in
limited cases, where it is well known that there is no danger (such as in the
case of the USB bus) a trusted system bus controller may grant access to a
specific unused device to an untrusted user-loaded program.
> > 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.
>
> My point exactly. You cannot depend on users to take responsibilty.
> A malicious user, especially.
I agree. However, the proposed model does not depend on the users taking any
kind of responsibility for the security or correct operation of the system.
It is the bus controllers (necessarily trusted software components) that are
responsible for ensuring the security of the system.
> > 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.
> 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. 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. The proposed model
limits such potential weak points to the bus drivers themselves (including
e.g. PCI drivers which can become bus controllers). The remaining device
drivers need only be a trusted as the clients that depend on them -- which is
one of the fundamental reasons for using a microkernel in the first place.
pgpkHOcxFWDhg.pgp
Description: PGP signature
- RE: Reliability of RPC services, (continued)
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
- Re: Reliability of RPC services,
Jesse D. McDonald <=
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/26
- Re: Reliability of RPC services, Jesse D. McDonald, 2006/04/26
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/26
- Re: Reliability of RPC services, Jesse D. McDonald, 2006/04/26
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/27
RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
RE: Reliability of RPC services, Christopher Nelson, 2006/04/27