There would be three classes of accounts:

User Account:  No Internet access.  Can send and receive mail only to
local Grex account, use Unix shell, participate in party and the
conferences.  

Community User Account:  Full E-Mail.  Users can send and receive email
from or to any address.  

Validated User Account:  Full net access.  Full access to the Internet,
including telnet, ssh, ftp and http. 

All new user accounts would be created in the User class.

Promotion from the User class to Community Users class would be by
responding to a email sent by a Grex Helper which asked the user to
identify where or how they found out about Grex.  

Promotion from Community Users to Validated Users would require the same
validation that is currently required for membership, either a photocopy
of a government or school issued ID that contains the person's photo, or
by a $1.00 payment through Paypal.  

Once an account was Validated, it would not need to be revalidated. 
Validated User accounts that had not been active for more than a year
could be reaped at the end of that time.   Becoming a member would be
sufficient, but not necessary for becoming a Validated User.

150 responses total.

I would support that. 

First edit:

Change line 1 to read there would be

First Edit:

Replace "There would be" in then first line with "There shall be"

I support this.

I support this.

May I make a suggestion?  I think access to compilers and interpreters
(except for the shells, of course) should be restricted to validated
users.  This would prevent many of the attacks that come from the inside.
Are there any non-shell scripts (e.g. perl or python) that are essential
for non-validated users?

I'll go a bit further and suggest there be some speed bump to people being 
able to POST to the conferences.  Not necessarily social validation, but 
something that would require Grex sending mail to the user and getting a 
response back.  This is a pretty standard expectation out there for good 
reason.  Sad but true.

Along with my suggestion in #6, you might have to prohibit non-validated
users from being able to upload precompiled programs from elsewhere, too.
Or is there a way to prevent programs from running from the user's home
directory that I'm not aware of?

resp: #8 

You could put unvalitated users' home directories in a folder on another
slice, and mount that slice noexec. Part of the "turning up" script that
is run when they are validated would migrate their home directory to
/home (or /users or /export/home or /a or /c or wherever we are putting
users' directories). 

resp: 9 

I forgot a couple of things. Warn users to use ${HOME} instead of
hard-coding something like "/export/home/m/a/maus". 

You could update newuser to only give the choices of party or rksh or a
menu and this would also limit the damage. Maybe part of the validation
email would require the user to pick a shell from a broader list (like
full ksh or bash or tag-c-shell) if they want. 

Or send the two big, mean leather-dykes named Guido (Hi, Guido) to rough
up anyone who intentionally tries to break grexserver. 

Could I have some proposed wording changes here, please?  

The wording changes need to be to the above proposal.  Please
distinguish between policy and what staff would have to do to implement
the policy.  

We do not need to include directions to staff on how to make it happen.
 Only what we want to see as a result of staff actions.  

Mary, I'm with you, and think we should remove the ability to
participate in conferences from User to Community User.

Unicorn, could you give a suggested wording that would put "access to
compilers and interpreters other than shells"  into the Validated User
group.  Is that sufficiently precise that a staff member could implement
it?   How would you word "upload precompiled programs" if it needs to be
a separate policy? Or is there a wording that would give staff the
go-ahead to do what you and maus are suggesting?

Well, for my suggestions, the first and third sections could read as
follows:

 User Account:  No Internet access.  May not compile programs or run
 user-written scripts except shell scripts.  Can send and receive mail
 only to local Grex account, use Unix shell, participate in party and
 the conferences.

 Validated User Account:  Full net access.  Full access to the Internet,
 including telnet, ssh, ftp and http.  May compile programs and run
 user-written scripts.

cmcgee, your response slipped in ahead of mine.  I think that "May not
compile programs" would imply that uploading precompiled programs is
also forbidden.  Or do you think it needs to be explicitly spelled out?

Maybe this would be clearer:

 User Account:  No Internet access.  May not compile programs or run
 user-installed programs or scripts except shell scripts.  Can send
 and receive mail only to local Grex account, use Unix shell,
 participate in party and the conferences.

 Validated User Account:  Full net access.  Full access to the Internet,
 including telnet, ssh, ftp and http.  May compile programs and run
 user-installed scripts.

Changing "user-written" to "user-installed", and adding "programs" in
the first case should make it clear that compiling elsewhere and
uploading is also forbidden.

I endorse bringing this to a vote.

(And suggest that folks consult the bylaws regarding timelines &
endorsement requirements.)

I loved the origianl draft (#0) - don't like the modifications! A LOT of
people use Grex to code and don't want to waste time on party and the BBS.
Our offenders are a few well known pests, why force the large mjaority of shell
users to suffer our community needlessly <g>. In any case noexec won't solve 
the problem, they'd just put the stuff in /tmp.

Well, noexec could just as easily be used on /tmp, couldn't it?  And
I'm interested in how you know that a lot of people use grex to code
if they don't spend time in party and the BBS to tell you about it.
Besides, nothing's stopping people who want to code on grex from getting
validated so they can do so.  It won't cost them anything, after all.

A standard practice should be to have /tmp and /var/tmp nosuid,noexec
for precisely this problem. Requiring validation does not introduce an
unreasonable barrier to being able to write and execute custom codes,
but does provide a control to deter pests.

vivek, I'm curious about what impact you think validation would have on
the users you are talking about.

This response has been erased.

This response has been erased.

Re #21: people may leave.

what is causing them to leave?  Is it because they have no way to be validated
(like Paypal)?  Is it because they don't want to be validated even though they
could be?    

Is it because a shell account isn't enough to teach them anything?  

What are they getting out of Grex that would change?

Re #25: "Is it because they have no way to be validated (like Paypal)?"

No easy and quick way to validate - college students using credit cards
are more the exception than the norm out here, so they'd have to ask
parents or friends - It's not that they don't want to pay 1$. That's
just 40 Rupees or 4 Pepsi glasses or 4 ball-point pens - nothing! What
makes it messy is the credit-card/parent required bit.

"Is it because a shell account isn't enough to teach them anything?"

Shell access is a convenience the way i see it - most of them will just
download and install Windows/Linux, but what if you want to access Unix
from a college computer in the browsing center? Grex provides a easy,
uncomplicated and quick way to get to Unix without the hassle of
tackling a complicated install. Most people will have Windows and data
taking up the whole drive, so they don't need to repartition when they
use Grex.

"What are they getting out of Grex that would change?"

Right now you get perl, ruby, python, gcc, g++, expect, man, mail, vi,
bash, csh, ksh, mount Gahh! You get everything right now, a whole BSD
box with bells and whistles in less then 1 minute after you hit Grex's
telnet port. If that isn't great I don't know what is! Have you seen the
hoops the other shells make you dance through!

"what is causing them to leave?" - Once they finish their course,
project, loose interest they leave. They aren't a part of this community
- they use the box to learn and they don't want to waste their time with
trolls and clueless noobs . Look at Gina, she left because she wasn't
getting any return on her investment - i can barely scratch out a
program, Chad goes hohoho - what the heck is she going to do on party? 
Same story on the BBS, given that we compete against Google.

WE DON'T HAVE PEOPLE - the only reason new people come here is because
of the shell - raising the entry bar will make things harder for sane
people to get in.

Don't complicate matters for now, 1 easy and small step at a time. Let's
first restore mail for non-troll accounts (Community User Accounts).
Then opening up web access to some of our forums (hardware, science,
unix, kitchen, music, books) would be the best possible advertisement
and should get us some users (Captcha is a must for backtalk).

Then if all else fails, we will be risking less when we ask our regular
hello.c users to validate shell (this would be our very last resort -
death rattle as i see it <g>).

I really don't think we should restrict access to things like compilers and
interpreters.  Honestly, I don't see that it's going to make much of a
difference.

I do, but the issues remain issues.

Okay, maybe requiring validation is too strict, but since it *is* how
much of the abuses are coming about, I think it shouldn't be automatic
for new users.  Being able to use compilers and interpreters is a
privilege, and those who are abusing the privilege need to have it
revoked.  Automatically giving that privilege to new users prevents
that.  Treat it like access to e-mail.  There has to be some way
to ensure that the people who have access to those things are not
likely to abuse it, and maybe one of the things that needs to be
checked is where they're connecting from.  If it's a Tor host,
they shouldn't be given access.

The shell is an interpreter; should we cut off access to that, as well?

I would submit that most of the abuses (a) don't affect the vast majority of
grex users (who never use the conferences or party, etc), and (b) are due to
known issues with software that we have installed, poor or outdated defaults,
etc.

Cutting off access to compilers and interpreters because of a few bad eggs
is like moving your house into a secure vault because a fly got through a
hole in your screendoor.  Ie, it is not an appropriate response given the
level of threat.

Re #29: Great points. I agree that anonymous-hosts should be given a
restricted-shell, but it's going to be hard to implement? We'll need to
modify login to change the shell every time it's a anonymous-host? What
if he uses loopback/su/login?

Right now i feel we should push #0 through without delaying that! We can
always discuss the modifications, get some working code and then push
that through as a separate proposal at a later date - if required.

I'm not up on the various shells and such, though I realize that's all
of what apparently  many users only access.  So to what extent they can
or can't provide problems to grex, I  haven't a clue.  But it there ARE
ways to use them easily to cause problems, then I agree  that there
should be different access levels.

The stuff that I do notice, of course, are the people that abuse the
conferences, party,  emailing, that sort of thing.  So I agree with Mary
in her response that we should do some  kind of validation before
newusers are allowed to post.  Of course, by being able to READ  the
conferences, they may be [more?] interested in becoming validated [or
maybe not].

> I'm not up on the various shells and such, though I realize that's all
> of what apparently  many users only access.  So to what extent they can
> or can't provide problems to grex, I  haven't a clue.  But it there ARE
> ways to use them easily to cause problems, then I agree  that there
> should be different access levels.

(This response isn't really directed at Denise, she's just the latest
to echo a sentiment that I am strongly opposed to..)

So here's the thing..  I hear people talking about "we must do this"
or "we need to do that" to protect the system, and I hope that before
anything rash gets decided we can step back and take a look at the
problem dispassionately.  That's not always easy when someone keeps
poking at your tender spots, or dancing around going "hey! look at me!"
but it's kind of important to try.

I'm going to tell you a little parable I made up, which I will call
"The Parable of the Vandal."  So without further ado..

--

                           The Parable of the Vandal

Once upon a time there was a happy family who were friendly and
hospitable to everyone who came to visit them.  The doors of their
house were never locked, and they were known far and wide for their
hospitality.  Strangers from faraway would come and stay whenever
they were in the area and the family derived great joy from meeting
new people and making new friends.

But one day, a bad man came along.  "I don't like these happy,
friendly people," he said.  "I'm going to teach them a lesson."
And the bad man took a rock and threw it through the window of
the house, where it broke a vase which was a family heirloom..

When the family saw what had happened, they were saddened.  The mother
said to her son, "Well, I suppose it was inevitable that this would
happen eventually.  Junior, go help your father put these shutters on
the windows so this can't happen again."

The next day, while the family were out shopping, the bad man came
back and pried off the shutters with a crowbar, broke another window,
and threw a rock, breaking a small delicate bowl that had been a gift
from one of their guests.

When the family came home, they said, "Shutters were not enough.
We must put boards over the windows and cover them with iron
bars.  Then nobody will be able to throw things through the windows.
This was true, but then the house was dark and they no longer got
to enjoy their view.

On the next day, while the family was in the back yard, the vandal 
walked right in the open front door and dumped a bag of garbage on
the living room rug, then walked out the way he had come.

"We can no longer leave the door open," said the family.  So they
bought locks and bolts and closed the door tightly.

Unable to enter the house, the next day the bad man slashed the tires
on the family's car.

So they spent their savings and built a garage to lock the car in.

After the garage was built, the bad man came back and spray painted
a rude word on their front door.

So Father got a second job and worked hard to earn money to build a
tall fence around the house.  And when the fence was finished the
family bought a vicious guard dog and set it loose to patrol the yard.
The dog even bit Mother once when she tried to stop it from barking
at Junior.  But at least the bad man couldn't get in any more.

Unfortunately neither could anyone else.  The house was surrounded by
a tall fence, guarded by a vicious dog, the door was locked and bolted,
and the windows were boarded over and covered with iron bars.  Even if
visitors *had* been able to get in, who wants to visit a prison?
Plus, the family no longer had the time and money to entertain guests,
nor did they trust strangers any longer.

And they all lived unhappily ever after, even the vandal, who,
after all, was a miserable person to begin with..

 So what's the point of my parable?  If it's not obvious, I guess
 I didn't do a very good job, but what I'm hoping people will take
 away from the story is that (a) the vandal will attack any target
 of opportunity.  Unless you lock things down so as to be hopelessly
 restricted and unattractive to pretty much everybody there will
 practically always be something the vandal can do to annoy you;
 (b) it's much easier (less expensive in terms of resources and
 time spent) for the vandal to attack than it is for you to defend.
 (c) in the end, destroying the things that attract people to the
 system is a poor strategy.

Mike, always the voice of reason. :)

I thought the parable was very nice, though I thought it would work equally
well as the Parable of the Terrorist and the Lost American Freedoms.

Mike, I like the story.  It's a scary one, for sure.  Good thing nobody is 
talking about doing the same with Grex, eh?

Well, bit in a way, they are.  And *talking* about it isn't necessarily a bad
thing, of course, but *doing* some of it would be.  For instance, I really
think it would be bad to block access to compilers and interpreters, for
exactly the reasons Mike points out: too much effort for too little gain, and
at the end of the day, for what purpose?  Sure, we *could* turn off the
execute bit on any filesystem that the average Joe can write to, but then what
about people's personal "bin" directories?  It's just not worth it.

Well, I withdraw the suggestion, then.  If you feel we can deal with
the abuses without that, I respect your judgement.  I would really like
to leave those things enabled, but then I would really like to be able
to leave my house and car unlocked without having to worry about people
stealing my stuff, too.  I was just reacting to the recent abuses, some
of which I know were done with user compiled programs, and at least
one of the perpretrators has been talking openly about doing much more
of the same in the not-so-distant future.

By the way, the reason I felt that interpreters like perl and python
could be treated different from shells was because shells have generally
been less powerful, relying much more on external programs to do a lot
of their work, but thinking about it, that probably isn't so true,
anymore, considering that David Korn has stated that he wants ksh
to be as powerful as perl, and even zsh, which I use, has many more
capabilities than I am even aware of, not having had the time to read
the man pages and other dowumentation for it in their entirety, yet.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss