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

[Jonathan I. Kamens]

In article <12067 at mentor.cc.purdue.edu>, asg at sage.cc.purdue.edu (The Grand Master) 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.

  I am not your teacher.  It is not my job to teach you all about network
security, Kerberos, and security in a distributed computing environment.  I
have given more than enough information for you to be able to learn more about
these subjects on your own.  Go look up "Saltzer" in the indices of the CACM
for the last six or seven years.  Look up also "Steiner".  There are probably
others, but I can't think of them off the top of my head.  Also, ftp to
athena-dist.mit.edu and look in /pub/usenix (athena-dist is also accessible
via E-mail for people who don't have access to anonymous ftp -- send mail to
archive-server at athena-dist.mit.edu with "help" in the body for more
information).

  I have asserted that our "attach" is secure, and that root access to our
public workstations does not compromise our security.  I have offered to mail
to anyone who asks the archives of a lengthly discussion about why root access
to our public workstations does not compromise our security, and I have sent
that mail to several people, including you.  I feel that I have done more than
my share of meeting the burden of proof on the assertions that I have made.

  In response, you have simply asserted that arbitrary mounting is a bad idea
and that our system isn't secure.  You have offered no evidence to support
either of these claims.  When you offer such evidence, I will discuss it. 
Until then, this is the last I will say about either arbitrary mounting our
public workstation root access.

|> 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.

  One of the most important tenets of computer security is that you cannot
assume that anything not directly under your control is secure.  This is akin
to the assumption that your "opponent" who is trying to violate your security
knows everything you do.

  As I said in my last posting, MIT has a large wide-area campus network with
machines controlled by many different organizations on that network.  Many of
those machines are single-user Unix workstations or Macs or PCs.  Our network
services staff cannot spend their time watching over every one of the
thousands of the machines on the network, making sure that people on it don't
do anything they're not supposed to do.

  Therefore, we have two choices: Either we can restrict who gets network
access so only machines that are directly and cleanly controlled can be on the
network, or we can develop an authentication system that allows a high level
of service and is not compromised by root access to machines on the network. 
We have chosen the latter.

  Purdue's security (and the security of any other Unix site that trusts root
on remote machines) is dependent on every machine on the network being secure.
If one machine on the network is broken into, the entire network is
vulnerable.  Kerberos authentication does not have that vulnerability.  It was
created to avoid that vulnerability, among other things.  The computer
industry has accepted it as a standard (for example, the OSF DCE uses it, and
Ultrix 4.0 comes shipped with it, and 4.4BSD will come shipped with it as
well).  Your assertions that we should move back into the stone ages of
trusting every machine on the Internet to be secure is therefore somewhat
suspect.

|> 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.

  Security that depends on the good graces of every admin on your network is
no security at all.  Furthermore, it DOES NOT SCALE.  The more machines you
have on a network, the more people you need to run them, and the more people
there are running them, the more possibility there is that someone will start
playing around with root access.  Kerberos avoids this problem.

  I wonder -- if I snarfed the entomb software from Purdue and figured out
from it how the entombd stuff works and what RPC port requests are sent on,
could I su to root on my workstation and send requests to an entombd at Purdue
to remove somebody's files?

|> 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.

  A workstation, perhaps.  But perhaps not a PC, or a Mac, or the portable PC
that your opponent carries into a lab and plugs into your ethernet when no
one's looking.  One of my coworkers has an ethernet card and software in a PC
that weighs ten pounds.

  Furthermore, the machines on our network are on the Internet.  We cannot
control the entire Internet.  And restricting access to the Internet handicaps
our users unnecessarily.  I say "unnecessarily" because, as I've pointed out,
the security of Kerberos makes it unnecessary for us to worry about root
machines elsewhere on the Internet.

|> }  Users being allowed to mount other directories at will is a logical
|> }extension to the ability to mount remote filesystems.  Placing unnecessary
|> UH - no

  Look.  The reason that mount(2) was originally restricted to the superuser
is that non-root access to it introduced security holes.  If the security
holes are no longer present, then the only reason for restricting mount access
is no longer present, so it is logical to remove that restriction.

|> }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.

  If the only reason for a restriction is for security, and if removing the
restriction no longer causes security problems, then there is no reason for
the restriction and it is therefore "unnecessary."  This logic is not very
complex.

|> 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?

  This was all discussed in my postings in alt.security.  People who are
interested in it can E-mail and ask me for a copy.  I am not going to debate
here what was already debated at length there, to the point where there was
just nothing left to say.

|> 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.

  You are almost certainly guessing wrong, since (a) this is an incredibly
inefficient way to accomplish the required goals, and (b) most vendors'
implementations of NFS do not allow transparent exporting from one fileserver
of filesystems mounted from another fileserver.

  It is more likely that GE is using an automounter of some sort. 
Automounting is a good idea, and has some advantages over the way Athena does
things (although there is as much of a delay when an automounter mounts a
filesystem as there is when our "attach" does it).  Unfortunately, many
vendors do not provide enough kernel support to make automounters work (since
they usually work by attaching a process to a directory as an NFS server, and
many variants of Unix don't support that), so Project Athena (which requires
multiple-platform support as one of its highest priorities) decided to go
another route.

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

  There are security concerns.  But, as I have said from the very start, those
concerns are addressable.  And if you fix the security problems, then there is
no longer any reason to prevent non-root mounting of remote filesystems.

|> 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.

  Um, excuse me, but in message <11941 at mentor.cc.purdue.edu>, you wrote:

|> Is this system source code? If so, I really don't think you should be 
|> deleting it with your own account.

In other words, your original assertion which started this whole thread is
that I should not be able to write to the source code with my own account.  So
which is it, that I should be able to write to the source code or that I
shouldn't?

|> 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.

  Accountability and trust are two different things.  We trust the people who
work on our source code, but we still need to know who makes what changes. 
Accountability is a recognized necessity in virtually every branch of
engineering.  It's why architects sign their drawings, and why RCS and SCCS
store usernames.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710