Project Athena ( was Re: Non Destructive Version of rm)

[Charles Clark]

asg at sage.cc.purdue.edu (The Grand Master) writes:
>jik at athena.mit.edu (Jonathan I. Kamens) writes:

>Sorry, I just don't understand how giving anyone the right to mount
>any filesystem they wish, and then giving them root access to boot 
>does not at all compromise system security. Maybe you can explain this.

That is because you just don't understand the concept of authenticated
file systems.

>Now it depends how you hook the Macs and PCs up to the network. 
>And also, dunno about your PC's, put the Public PC's at Purdue
>DO have accounts for special functions, and you are not allowed
>to mess with certain things without the right authority (kind of
>a root-type idea)

So in other words you only allow Macs and PCs on your network that are
centrally administered?  That SUCKS.  Furthermore you are going to have
to pay for a LOAD of support and administration personnel ...

AND I really don't think that your pcs are half as secure from user
tampering as you apparently do.  Macs and PCs are fundamentally
insecure OSs.  You allow me to run programs on one of them, and I WILL
be able to break your security.  No doubt about it.

>Now, if you are saying that the people in the computer dept do not
>know if they can trust the SYSADMINs in the MATH dept, well then 
>you should do something about that.

Sure.  On a campus of some 40000 (just the students, not faculty and
staff) we are all just going to have to trust each other.  Right.
Stupid idea.

>A workstation can be made such that you cannot boot it from floppy
>without a passwd (in fact my PC even does this), so physical 
>access is not really an excuse.

Right.  Physical access to almost any machine, and some knowledge, will
breach security.  Deny reality if you want to, that is your problem.

Besides, the reality is that we (and athena I assume) want to share
files among many machines, right down to the macintosh in some
student's dorm room.  We can't assume a) centrally administered
machines and we can't assume b) trusted machines.  If all you want to
do is share files among trusted centrally administered machines with NO
other machines being allowed to connect on your subnets then fine, just
MAYBE you don't need to make the assumptions that you are making and
you can get away with it.

But I would rather have an athena like environment than something like
what I just described even if I had to use a pretty wimpy workstation
instead of dialing in to your sequent thang.  I'd rather deal with
authentication than big brother anyday.

>It is not an unnecessary restriction. Again, Why don't you tell us how
>it can be that I can be allowed to mount any filesystem I choose,
>log in as root, and still not do harm to the any of your systems. 
>At the very least, can I not wipe the entire root directory of the
>workstation clean?

I don't know the athena implementation enough to answer your question,
but I do have enough experience to know that a system can be configured
such that the user can gain NO access to files he/she shouldn't have
access to and where wiping what they can as root loses no data for the
administrators.  Where restoring the usability of such a wiped system
does not take very long (hell, I'm not sure but I don't even think a
person with special priviledges would necessarily be required).  So
what do I the user gain by being root and doing something like that?
When anyone can do it and it accomplishes nothing except annoy other
peers who wish to use the system, why would I do that?

>Of course you cannot assume that every machine on the network is secure.
>you can however assume that some are secure (like your own) - that is
>if you are capable of correctly administering them.

No you can't.  You can't assume a particular machine on a network is
secure unless the network itself and all machines on it are secure.  I
don't think you've really thought about this very well, or maybe you
just don't understand how these networks work.

>There are also risks involved in allowing people to mount remote filesystems.

Not if you don't "trust" them.  And whether you believe this or not,
the concept of trusted systems is almost universally agreed upon as a
HUGE security risk.  Especially when you don't NEED to trust them and
can still accomplish the same tasks.  If you'd think about it, having
users able to mount remote filesystems as well as doing it the old way
is an extension of functionality.  So, if you can do this without
breaching security, why NOT?

Too flexible for ya, or what?

>It might be a little easier for you to have to include NO NO NO commands
>because you are in the source group which has write access to the source
>files.

That can be done in an authenticated manner on an authenticated file
system too.  Whether or not certain groups of people working on common
source chose to do it that way or not is irrelevant; they may have
their own extra concerns that dictate that choice and I just don't care
what they are!  The fact is that the distributed (at least with afs)
way isn't more complicated unless you choose to make it so.  And you
can choose to make it so on the non-distributed way as well.  IE,
neither method is a particularly big win or lose in this respect.

>}Authenticating to a restricted filesystem is a
>}one-step operation, and the authentication stays until you revoke it (or until
>}it expires), just as logging into a special account stays until you log out.
>}
>Being in a group that has write access to a directory tree takes
>NO STEPS AT ALL. Hmm, I guess that would make it alot faster tha
>your one-step process.

Not really.  The "one step" to authenticating can be the same one step
you use to sign on.

>                                   ###             ##
>Courtesy of Bruce Varney           ###               #
>aka -> The Grand Master                               #
>asg at sage.cc.purdue.edu             ###    #####       #
>PUCC                               ###                #
>;-)                                 #                #
>;'>                                #               ##

You seem to think you are being clever and poking a ton of holes into
the athena design philosophy.  Give them a little bit of credit.  They
have been using their system for years now.  They don't seem to have
the security problems that you don't seem to understand how they don't
have.  They don't seem to have the functionality problems that you keep
trying to add in to their system.  It can't be from a lack of
users too dumb to break into the system, this is MIT; besides you will
find people capable of exploiting security problems at almost any
institution.  I will use an arguement that you used in support of your
entomb stuff; IT WORKS.  It is in use right now.  The MIT guy is not
talking philosophy, they have useable systems (MANY) operating like
this right now.

I also suggest that the people there probably use and
have used more standard unix systems, but that you have shown your
ignorance about the feasibility of an athena type setup in abundance.
I'm not saying that athena is perfect or even the best around, just
that you are not proving much besides that you don't understand it with
your comments.  And it isn't somebody from MIT's problem to educate you
about distributed computing and authentication issues; if you want to
dabate these issues it is YOUR problem to cure your own ignorance.  I
am SURE that with the fine libraries and computer access available at
Purdue, a top notch institution in its own right (I practically flipped
a coin to choses between Purdue and UofMichigan, and if Michigan didn't
have a liberal arts school of great recognition on the same campus I
doubt I would have come here.  And oh, yeah, the other place I applied
was MIT.  I'm not trying to knock Purdue vs MIT or anything in any of
my comments here) you will be able you find more and better information
on these subjects that you will get argueing on comp.unix.admin.  That
is, unless what you really want is to argue, or you are totally close
minded.

cmc			<Charles.Clark at terminator.cc.umich.edu>

ps.  Athena can add a couple "powerful" central type systems for
dial-in or x-server access.  If they don't already have such.  Your
system won't adequately and especially securely support the small
decentralized machine or group of machines.  Need I really say more?