Re: Reliability of RPC services

[Marcus Brinkmann]

At Wed, 26 Apr 2006 17:02:32 -0600,
"Christopher Nelson" <address@hidden> wrote:
> 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.

Tightly locked down configurations like an "internet kiosk" or a
"photo download station" or a "multi-media terminal" are so far away
from being a general purpose computer that it doesn't make much sense
to call the human interacting with the machine a "user" in the sense
that we are talking about users (with an account) in this discussion.

> > > 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.

The problem is that the user could access the network cable, not that
he could run his own drivers.  He could just as well bring his own
laptop or PDA.

> > > 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.

No general purpose operating system in its default configuration will
get you this tight a straight jacket.  You would have to pay me a lot
of money to consider such a case, and even then I might refuse.

See, I really don't see what the problem is you are trying to solve.
A user can only start their own drivers if their virtual terminal
description contains a capability to the respective hardware.  In none
of the examples you gave the user would even have a an account on the
machine, so all the programs that are run are under the explicit
control of the system administrator or whoever else is responsible for
maintaining the software on the machine.  I really don't understand
what you are objection to.

> > > 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.

I carefully considered the case and rejected it.  I do not expect the
user to be computer savvy, but I do expect that some people are
malicious.  I don't see any contradiction in any of this.

See, I am working on this on my own time, with my own resources.  On
my list of problems in the world I want to solve, the problems of
system administrators in a business that doesn't want employess to do
whatever they want to computers the business owns are way, way, way,
way, way down the list.  The mechanisms to achieve that level of
control are fairly obvious and provide no intellectual challenge.  The
underlying assumptions about relationships of power I find objective
and immoral.

Nothing of this means that it is impossible to build such a system
using a different default configuration.  In fact, it is very easy to
do.  I probably will not do it for you (unless you can convince me
that your specific use case is worth for me to support).  But there is
also nobody stopping anybody from going there.

> > 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.

This is a good argument for making it harder 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.

I have some theories about that, but indulging into them would by far
exceed the topic of this list, and this discussion.  However, I would
advice that you maybe should ask yourself the question if
disempowering people is the right way to make them more responsible.
(Chicken and egg problem?  Maybe.)

> > 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?

I don't.  But the computer at your workplace is not "another person's
computer", nor is the computer at my library, university, or museum
"another person's computer".

Thanks,
Marcus