l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Reliability of RPC services


From: Christopher Nelson
Subject: RE: Reliability of RPC services
Date: Wed, 26 Apr 2006 17:02:32 -0600

> At Wed, 26 Apr 2006 14:48:13 -0600,
> "Christopher Nelson" <address@hidden> wrote:
> > 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.
> 
> Random people don't even get access to YOUR computer, so what?

Huh?  If you mean that they don't get access to my personal computer,
that makes no sense.  If you mean that they don't get access to the
computer that I'm using, that may be true, but I still don't understand
what you're saying.  If they get access to a computer that I am
administrating, then it does matter.  And random people do get access to
computers that I administrate.
 
> When we are talking about systems that are set up by one 
> group of people and accessed by another, then almost always 
> we are talking about systems involving the public to some 
> extent.  For example, library terminals, workplace desktop 
> computers etc.

Yes, I know.  This is what I meant.

> In these cases, it will not be what the system administrator 
> wants alone that counts.  Instead, there will be negotiation 
> in public at many levels, and the final result will be 
> something that is subject to policies that will always be 
> public to some extent.  

That's not true in many respects.  I work at museum, we have public
kiosks.  The kiosks may or may not provide a service that is useful to
visitors.  We try to make it useful, but in the end the public has no
say regarding what is or isn't on or attached to these systems.  We, the
system administrators do.  Some of these are technical decisions, others
are liability decisions.  We have a public library that's a case in
point.  Many people would like the system to be more open than it is,
but we simply cannot trust them to behave, so it's tightly locked down.

> > 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.
> 
> Uhm, to what network?

To the network that the computer is plugged into.

> The one on the USB network card 
> interface?  If you give someone access to a network via a 
> port, how can you prevent them to hook up any device they 
> want to the network, without actually sitting behind them and 
> hitting them over the head?  This example doesn't make any 
> sense to me.

I'm sorry, let me rephrase.  The computer has some network card plugged
in to a PCI slot, and it's setup for a certain kind of access.
Generally it might just be standard IP over Ethernet.  It will behave
properly, because we trust the IP stack that drives it, and we trust the
settings because we set them up.

Now, if you can plug in your own USB network card, and hijack the
physical connection (usually pretty easy), then load your own driver and
network stack, there is a lot of damage you can do to the network.  You
can spoof packets, you can flood the connection, you can do any number
of malicious things.  This is all very easy because you wrote your evil
driver and network stack at home, and then came in and just ran it.  You
didn't have to bypass any security because you brought all the stuff you
needed with you, and the system doesn't see any reason to stop you from
doing what you did.

> > I don't want you to hook up a camera or a scanner that you 
> can use to 
> > steal sensitive documents.
> 
> If I have access to sensitive documents, I can already steal 
> them.  If a camera or scanner is nearby, then it's even 
> easier (with computer or without).  Plus, I may even be 
> morally (and legally) obligued to steal them, for example if 
> they are evidence of criminal activities that is in the 
> danger of being destroyed for cover-up.

Yes, and you may be legally obligated *not* to steal them.  Consider the
case that we have sensitive documents on microfilm.  The microfilm is
kept in a vault, and you can't take it out of the vault.  The computer
you use to read it is in the vault with you.  A secure program is used
to allow you to view the microfilm, but not to print it out, save it, or
transmit it.  But here you come, with your own driver and/or scanner,
plug it in, and copy all of the stuff off of the microfilm.  This is not
made up, it is essentially what happened to our institution a few months
ago.

> > 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.
> 
> Obviously, you will then not use the Hurd.  Not only for 
> this, but for a number of other reasons as well.

That may be the case.  It would be a shame, but it might be the case.  I
think that you should carefully consider the use case of "business
doesn't want employees doing whatever they want to computers the
business owns."  Not so much because the users are malicious, but
because they are not computer savvy, and some people *are* malicious.

> As people will become more computer literate, and computers 
> become more ubiquitious, there will be a struggle of the 
> users against the system administrators.  Users will slowly 
> wrestle more control over the computers _they_ use.  It will 
> then become the job of the system administrator to allow that 
> level of control and to make it safe at the same time.  It 
> will be more difficult, but they will have to learn to deal with it.

I don't think that I agree.  People have to become more responsible
before I feel comfortable giving them wider permissions.  Even so, why
do all systems recommend that you don't run as "root"? Because it's too
easy to shoot yourself in the foot.  Giving people permission to do
something, and making it safe requires that people take more
responsibilty for their actions.  This is a social issue that no OS will
solve.  I see people becoming far *less* responsible, not more.

Consider, why does the MIT $100 computer effort focus so much on giving
people their OWN stuff?  Because when it's YOURS you take better care of
it.  People in general do not take care of public property, or of
business property.

> Don't believe me?  It has happened before, take for example 
> the doctor-patient relationship and how patients have become 
> a bit more in control over their health care in the recent 
> decades (at least in Germany).  System administrators today 
> are "gods in white robes", as it happened so often in history 
> where a new technique was developed which was not yet 
> understood widely.  But that's just for the moment, it can 
> change and it will change.

Yes, but that is a person's own body.  I think that you should have
control over your own computer to the Nth degree.  You do not expect
control over another person's body, so why do you expect control over
another person's computer?  
 
> The Hurd will be an operating system that welcomes 
> participation and self-management by the users.  It will 
> de-emphasize the system administrators role.  It will not be 
> a good tool for dictatorial control, but it will protect 
> users and applications from each other and from mistakes.

That would be cool, assuming that users are responsible enough to do the
right thing.  But if you look at how humans in general have managed the
planet, you will see that I have little optimism in people responsibly
managing other people's property.

I want to emphasize that I'm not against the principles that the Hurd
embodies.  I think it's awesome.  I simply feel that the particular
security mechanism mentioned in this thread is not technically feasible
for the many reasons I have enumerated. 

-={C}=-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]