was "RE: Homelessness and the web", now shell access

[Kurt Cockrum]

[sorry this is so long, but I'm trying to cover as many bases as I can.]

jj said:
>> [....]
>> resend the following paragraph.  SCN should seriously consider this
>> policy change: let everyone have shell access if they want it.  If
>> Speakeasy can do it without it becoming a security hassle, why can't we? 
>
>Speakeasy also has full-time (= paid) staff.  Does this make a difference?

Well, currently SCN pays one person.  Can they handle two?  It's conceivable,
particularly if wage parity with current practice isn't a constraint.  Going
into the commercial market for a "real" sysadmin (the kind that make $75K/year)
is a sure-lose IMO, because they'd be gone as soon as they got a better offer,
and they'd be as much of a continuing resource-sink as rent payments to a
landlord.  As much as possible, we need to cut loose of conventional market
mechanisms, because they just don't serve our needs, and in fact, for us they
are downright counterproductive, the sort of thing our enemies (if they exist)
would design for our benefit.

On the other hand, paying somebody a subsistence wage might provide great gains.
Lots of the most effective social change organizations do that.
Somebody with a social conscience, a desire to do some technical good, and some
experience, and for whom a frugal lifestyle is not a problem, would fit the bill
nicely.  I can think of a few people who would be likely candidates, mostly
people we all know and trust.

That person would have to be able to work closely with the hardware gang
[oops, Operations Committee, so I hear].  The exact relationship might need
to evolve.

Can we get some info here on just what Speakeasy is doing? how many
sysadmins do they have?  what's their workload?  What's their configuration?

>I suspect so--our volunteer staff (e.g., me) don't put in the hours to
>stay on top of problems. 

I don't really believe that.  First of all, "staying on top of things"
is a state of perfection, not a norm.  Perception of the difference between
that, and how things "really" are is, on the other hand, evidence that
somebody cares.  A good sign.  The norm is that there is a difference.

Look, there is never going to be enough time to do all the things that
need to be done, no matter if you have an army of people.
This has to be accepted from the outset.  Moreover, it's
so universally applicable that I can't accept it as a reason for not doing
it.  It's also an issue that doesn't go away if you start paying people,
in fact that might even aggravate the problem.  We should not be paying
anybody $40/hr for 60-hour weeks.

I don't know if "staying on top of problems" is something that is successfully
done anywhere.  I know that you put in a lot of hours as a sysadmin, from a
lot of face-to-face we have.  Since you are the only member of the hardware
gang I have face-to-face contact with (meetings, while necessary, don't really
count because of their ephemeral nature), I don't know what the other people
in the hardware gang do, but I have to assume by default that everybody is
doing what they can.  So in a certain sense, this has to be taken as "good enough"
or "the best that can be done at the moment".

I think we have to cop to the possibility that for many things, they are
as good as they are ever going to be, considering the nature of SCN
(volunteer-driven, democratic, non-profit).  To make things "better" often
means giving up other equally valuable considerations, IMO an unacceptable
compromise.

I think such problems can only be "solved" by fostering situations where
as many people as possible can get the knowledge to solve the problems, and
letting native curiosity and intelligence do the rest.  This
can only be done by "learning by doing", i. e. shell-access.

>An even bigger difference: we don't really know who most of our users are. 
>Some Freenets require id--we only require a mailing address (and some mail
>gets returned to us).

What problem does "knowing who most of our users are" solve?
How does "requiring id" help that?  Are Freenets that do that better off
than the ones that don't (hard facts are needed here, not chicken-little-ish
legal qualms).

How does keeping FreePort-only access help us here?

Are you suggesting that the current system does not serve us well?
Need specificity here.  We don't *need* to know everything about our users.
We need not record their height, weight, color of hair, etc.  We absolutely
*do* *not* care about such things.  Our current registration system satisfies
all our needs (legal accountability), AFAIK.
Anything else is uncompensated labor for somebody else that provides no
benefits to us, just an energy-sapper.

>                       If someone decides to screw up--we may have no
>recourse other than turning them off.  They are certainly not loosing any
>money if they burn an account.

Well, if "turning them off" works, then that's what we do.  No change from
the current policy, AFAIK.

>And shell access is going to mean full Internet access.  (Even if we don't
>provide it, some users will be running slirp, etc.)  This could jeopardize
>our _free_ Internet access--it seems to have been provided with an
>understanding that we would not be providing unlimited access.  If we open
>it up, we could possibly have to start paying for it.  And have to start
>collecting from our users, with all those attendant hassles. 

shell acount != unlimited access

root priveleges == unlimited access

shell account == limited access

Just toss out the slirp executable, if necessary, or make it non-runnable except by
selected users.  Generalize from slirp to <whatever-executable>.
There are lots of programs already that aren't accessible to all shell users.
That's the reason sudo exists.
As far as unauthorized executables go, well, tripwire can find those.
Running SATAN informs of nettish vulnerabilities.
Running crack deals with silly passwords.
Setting umask system-wide to a sane value solves the problem of users granting
world write-access inadvertently.
Not divulging the root password to untrusted users helps.  Our current policy
serves us here (although we might want to know more about somebody who had
the root password than an ordinary user, per jj's concerns above).

Common sense covers nearly everything else.

The thing is, these utilities are a lot more tractable than FreePort,
and maintaining security in such an environment is going to be a damned
sight more doable than maintaining it in FreePort.

The likelihood of stumbling on new, unforseen relationships among regular
unix utilities is way less than the likelihood of the same thing among
(regular unix utilities + FreePort), and is likely to have been observed and
dealt with before.

For one thing, there's the whole usenet and years of existing practice to help.
This is not the case with FreePort (if it were, the problems would've gone away
by now; somebody would know all about interfacing Pine with FreePort, for example).

>With you patient readers that have gotten this far I will share my main
          ^^^^^^^ :)
>concern:  that 'consideration' of providing general shell access is going
>to be limited to 'gee, would that be nice, or what?', and not of the
>consequences that could ensue.

Well, no.  I hope we can do better than that.
The consequences are no worse (or different) than they are from giving
users access only to FreePort, but can be better, because of better tools
and more knowledge (available) with unix/shell.

My point is, that FreePort provides no protection from any foreseeable
consequences.  At least none that I'd have any confidence in.  In fact,
I wouldn't be surprised if FreePort might turn out to be one of the things
we'd get rid of if we wanted to protect ourselves from "consequences".

Is anybody willing to get up and say that the FreePort software has protected
us from "consequences" more than can be simply attributed to the basic decency
of the majority of our users?  (sorry, just assuming that it has, won't cut it)
In other words, do we have evidence that we'd have "less" bad guys with FreePort
than we would have by granting shell access on request?

All the evidence I see indicates otherwise.

>                                Like having to charge to pay for full-time
>sysadmins, or Internet access.  Not that this would necessarily happen.
>But has anyone considered it?

We are considering it right now.  I hope we can keep doing it.

Of course, there will be "problems".  I doubt if any of them will turn out to
be insoluble.  Will they be worse than what we've seen so far?  I don't know.
When's the next earthquake?  Anwer that, and you've answered the other.

We might someday have to go to some kind of a sliding-scale structure.
I'd have no problem with that.

As far as internet connections go, I would hope that there is a net-head
out there who stays on top of that stuff...maybe a volunteer is needed to
do something like that (monitor newsgroups, etc).  Maybe that's an area for
the "volunteer coordinator" to deal with.  Maybe CPSR has some smarts in this
area.

Anybody with more experience than me, or genuine horror stories about
granting shell access, that could've been preventable by FreePort
(or its equivalent, bugs and all), feel free to speak up.

I think I've answered all of the points jj raises and hope I've anticipated
most of the objections that haven't yet been voiced.  Fortunately for you
all, I've pretty much said all I need to say on the subject.
--kurt
* * * * * * * * * * * * * *  From the Listowner  * * * * * * * * * * * *
.	To unsubscribe from this list, send a message to:
majordomo at scn.org		In the body of the message, type:
unsubscribe scn
END