Grex Staff Notes -- Draft Versions Posted

Aug 28 21:37 UTC 1997

I've written a series of Web Pages called "Grex Staff Notes" that exist as
a way for the Grex staff to publish details of technical information about
Grex and to explain the logic behind staff policies on various issues.

I hope we will be able to keep these current, and add other pages of other
information.

The existing pages are currently at

        http://www.wwnet.net/~janc/grextech

There pages are:

 - Introduction.  Including some rationale for the staff notes and
   a list of staff members with some kind of clue about who does what.  This
   also has pointers to all the other pages.

 - Privacy Guidelines.  This is based on the document that appeared here in
   coop recently.  It outlines the kinds of circumstances underwhich staff
   might use their root powers to look at people's personal files.

 - Security Goals.  An overview of our system security philosophy and how it
   differs from more conventional systems.

 - Password Database.  This gives a very detailed description of how password
   security is implemented on Grex (with comparisons to standard Unix
   methods).  It talks about the shadow file, the hashed password database,
   and the password encryption algorithms.  It includes source code for
   Grex's password encryption program (one of Marcus's inventions).

 - Kernel Blocks.  This gives a very detailed description of how Grex's
   kernel has been modified to prevent non-members from telnetting out (or
   from running eggdrop and such like stuff).  It includes the source
   code for the kernel blocks.

These are all draft versions, and I'd be delighted to hear suggestions.  Once
we have more final versions, I'll move the pages to Grex (where any staff
member can update them) and set up links to them on our web page.

In particular, I'm not a real expert on the depths of the kernel or Marcus's
password encryption methodology, so the explanations there may be flawed.
If so, I hope we can correct them.

I've tried to address a broad audience with these.  Possible readers include:

  - People who want to learn about Unix and System administration purely for
    their own curiousity.

  - Administrators of systems with similar problems who would like to learn
    from our example.

  - New Grex staff members who want to learn their "jobs."

  - Hackers who want to find ways to crack Grex.

In any of these catagories, there are users with wide ranges of knowledge,
ranging from zero to much more than I know.  I'm trying to produce documents
that can be useful to anyone not at either extreme of the spectrum.

Explaining our security setup to hackers may seem like a bad idea.  But this
is definately something the staff thinks is a good thing.  There are several
reasons for this:

  - One of the fundamentals of good security is that you don't achieve it
    by crossing your fingers and hoping that nobody will notice the holes.
    Ideally, knowing everything there is to know about how our password
    system works won't let people crack it.  We don't believe that this
    information will actually help anyone crack Grex.

  - If we are wrong, and there are holes, then going public can still be
    positive.  Once we have moved the dialog about these into the public
    domain, we have made it easy for total strangers to send us mail like
    "I've been reading your password system documentation, and it seems to
    me that there is a vulnerability...".  Opening up a public dialog about
    these things means we are more likely to hear about it if someone sees
    a problem.  If you give information away, you are more likely to get
    some back.

  - Currently we have lots of people who try to do things like run eggdrop
    or run the "crack" program on Grex.  They use tons of bandwidth sending
    these things over to Grex, and tons of CPU compiling them.  However there
    isn't a chance in heck that either one will work.  So in many ways,
    ignorant hackers are a bigger problem to us than smart ones.  Ignorant
    hackers use up lots of resources finding out that we have decent security.
    We hope that educating our hackers by telling them in detail that we have
    decent security will discourage them from wasting our resources (and
    their time).

  - Anyway, openness is one of the things Grex stands for.  The fewer secrets
    we have, the more Grex we are.

One thing that we want to avoid is being too arrogant about our security.
Of course, there must be weaknesses.  We don't want to set ourselves up as
some kind of Holy Grail for hackers ("Think you're good?  Try and crack
*our* system?").  We're not that good, and we have better things to spend
our time on than dueling with hackers.  So the documents try to sound
competent but not arrogant.

Anyway, I've rambled on longer than I'd meant to.  Do look at the pages
(lynx should work fine -- there are no pictures so far), and let us know
what you think. 

Thanks.

response 2 of 28:

Aug 28 23:21 UTC 1997

(Clueless question)
How can grex publish it's password encryption program and stay secure?

response 4 of 28:

Aug 29 00:28 UTC 1997

 Because it is a one-way algorithm.  Older Unix systems had a world 
readable password database without much worry, because it would take too 
much machine resources to try all different possible passwords through 
the same algorithm, and you can't send an encrypted password back 
through and unencrypt it.  Now that faster machines exist, we hide the 
encrypted passwords.  But there isn't any need to hide the algorithm 
itself, especially since other systems might use the same one.

response 6 of 28:

Aug 29 15:07 UTC 1997

Yup.  There are two layers of security.  The first is that the encrypted
passwords are stored in a file that only "root" can read.  If a person somehow
becomes root, then he can see your encrypted passwords, but if he is root he
doesn't need your password -- he can already access all your files and
everything else on Grex.  Even if a person somehow does get a copy of the file
with the encrypted passwords, you can't use an encrypted password to log in.
You need to find that password that, when encrypted gives rise to that string
of garbage that is stored on Grex.  That's the second level of security.  This
prevents even the Grex staff from being able to figure out what your password
is.  (Of course, the Grex has root access so having your password wouldn't
give us any more power here on Grex, but many users use the same password on
other systems (never a good idea) so it's important that we not be able to
figure out your password here.)

response 8 of 28:

Aug 31 13:43 UTC 1997

I think I understand.  Thanks.

response 10 of 28:

Sep 3 01:55 UTC 1997

I've added a link to the Grex staff notes to Grex's web page.

I've also added another page:

        http://www.wwnet.net/~janc/grextech/pumpkin

This is a photo tour of the pumpkin, showing pretty pictures of all our crummy
equipment, with descriptive text.  There's even a map of (not to) the pumpkin.

It's the next best thing to being there.

response 12 of 28:

Sep 3 02:29 UTC 1997

It also has an actually photo of Steve Gibbard in action.

response 14 of 28:

Sep 3 23:22 UTC 1997

That's probably an illusion best spoiled.  ;)  

response 16 of 28:

Sep 4 02:26 UTC 1997

And don't forget the orange paint.

response 18 of 28:

Sep 5 21:00 UTC 1997

I also thought there might be holes in the wall from pounded heads and
fists when grex wasnt cooperating...but I guess Grex works so well theese
days that nobody gets taht frustrated.  But I'll bet in the old days at
the dungeon or something when grex was slower, using inferior equipment
and conections and more of ten crashed for unkonwn reason, there might
hvve been a hole or two punched somewhere eh?

response 20 of 28:

Sep 5 21:48 UTC 1997

how doyou put a hole in the *floor*?  hmm...wasnt grex in a basement?

response 22 of 28:

Sep 16 00:58 UTC 1997

The dungeon was also in a basement that had probably originally had a
dirt floor.  The ceiling was pretty low too, and it looked like the
concrete was basically just thick enough to mostly hide the dirt.  It
definitely wasn't thick enough to support the weight our heavier staff
members on a rolling office chair wheel.

I think it's safe to say we've made an effort to recruit grex staffers
who don't blow up or punch holes in walls.  Not that this was a specific
goal (although it does save on maintenance expenses), but we were
looking for people who would not lose their temper when dealing with
cantankerous hardware or users, and do something we'd all regret later.

response 24 of 28:

Apr 10 03:47 UTC 1998

I've been doing some updates on the Grex staff notes.  There have been minor
updates to many of the pages, and two new pages:

   http://www.cyberspace.org/staffnote/eggdrop.html
      Frequently Asked Questions about Eggdrop and IRC bots on Grex

      Yes, we got a couple hundred too many people asking about eggdrop or
      just trying to install it here without asking, so I put a pointer on
      the web-newuser page saying "click here if you are interested in running
      eggdrop or other irc bots on Grex" which leads to this page explaining
      why you can't run irc bots on Grex.  This was written before the
      change-over to the new system, and is slightly out of date now.

   http://www.cyberspace.org/staffnote/about.html
      About Grex's Hardware and Software

      This gives an overview of Grex's hardware and software.  It's not
      really finished yet.

I'd like very much any comments/suggestions/corrections/questions on these
pages that anyone has to offer.