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

[The Grand Master]

In article <1991May8.174603.26309 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
}In article <12049 at mentor.cc.purdue.edu>, asg at sage.cc.purdue.edu (The Grand Master) writes:
}  The *facts* are: people are willing to invest in distributed computing
}research; the computing industry has been devoting huge amounts of resources
}  In the face of this, you come along and assert that distributed computing is
}a bad idea.
}
Show me where I said this! What I have said is that your way of doing
distributed computing is bad.
}
}  Root access on a public workstation grants no special powers in our
}environment.  As I said, I will not debate that here.
no of course you won't
}
}  We give all users root privileges on public workstations.  That does not
}give them any access they should not have to our services.  As I said, I will
}not debate that here.

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.
}
}|> I know. That is the reason for the
}|> elaborate autentication system - but tell me, if you dinna let your
}|> users have root privs would you NEED the elaborate authentication
}|> system?
}
}  Yes, because it is impossible to insure that every machine on a network is
}secure.  We have a huge wide-area campus area network, with machines on it
}that are run by many different organizations, departments, etc.  We have Macs
}and PCs on the network that don't even have any *concept* of root privileges. 
}When you cannot assume that root is secure on all machines on a network, then
}you must assume that it is *not* secure, and that is why the decision not to
}hide the public workstation root password was made.
}
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)
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.
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.
}  One more time: I discussed all this in alt.security.  I will not debate it
}again here.
No, of course you won't
}
}  Once again, "If you don't know how Project Athena works, don't slam it."
}
}  Kerberos authentication is, for the most part, completely transparent to the
}user.  To a Project Athena user, logging into one of our workstations is no
}different from someone logging in at Purdue.  It was designed with that goal
}in mind.
}
}  If you don't understand how this can be so, I suggest you learn more about
}Project Athena, or be quiet.

Then why don't you tell us oh master of computing?
}
}|> and users being allowed to moun other directories
}|> at will,
}
}  Users being allowed to mount other directories at will is a logical
}extension to the ability to mount remote filesystems.  Placing unnecessary
UH - no
}restrictions on the user is antithetical to the original design goals of Unix,
}and furthermore, it's counterproductive.  If it is technically feasible to
}allow arbitrary filesystems to be mounted by the user, I fail to see how you
}can call it a kludge.
}
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?
}
}|> and users being given the root pasword, and then creating an
}|> authentication system to close up the wholes made by giving users access
}|> to root privs  - now *THAT* is a kludge.
}
}  The authentication system is designed to fix the fact that networks are not
}secure, and that you can never assume that every machine on your network is
}secure.  Especially not on the Internet, when we *know* that this is not the
}case.  This was discussed at length in alt.security.

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.
}
}|> I think that there are other viable solutions. But as I said, it is
}|> still possible to handle users directories on a net of 1000 workstations
}|> without your ridiculous kludge. As GE has done.
}
}  GE does it by cross-mounting all filesystems via NFS on all machines, right?
}Is it really true that you have 1000 machines, with all filesystems mounted on
}all of them?  I find that somewhat hard to believe.

Aww, you must resort to intimating that I am a liar eh?
I am not sure exactly how they do it.
If I had to guess, I would say that the disks of eact workstation are mounted
on a main server (say on /net) and that /net is then in turn mounted
on // for each workstation. Not hard to believe at all, and it is
quite workable.
}
}  In any case, you're right, it is possible to do it without explicit
}mounting.  That's why we're working more and more with the Andrew File System
}(AFS) here at Athena.  However, there are still advantages to being able to
}mount filesystems arbitrarily, since many people are going to be using NFS for
}a long time into the future, even if we start using AFS internally.

There are also risks involved in allowing people to mount remote filesystems.
}
}|> I feel the authentication is unneccesarily neccesary. You have made
}|> it a neccesity by putting power in the users' hands that should not
}|> be there. I will not applaud you for making things more difficult.
}
}  Um, how is it more difficult for me to have to type two commands in my
}current environment to get write access to the source tree (if I am allowed
}that access), while allowing to keep my entire environment, than it would be
}for me to have to log into a separate source maintenance account in order to
}modify the sources?
}
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.
}  And let's not forget that under the Athena system, there is accountability,
}because the changes made to the source tree are made by the user ID of the
}user who made them, not by a special source maintenance account.  To achieve
}that your way, you've got to have a separate source maintenance account for
}every person who's allowed to modify the source tree.
}
You seem to have people authorized to change source whom you
do not trust (or you wouldna need to have accountability). I suggest
that those peole be let go.
}
}  You don't have to do anything of the sort.  And I don't see how you ever got
}the idea that you did.  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.
 
}Jonathan Kamens			              USnail:

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