[232] in resnet
Re: remote access to public workstations at night
daemon@ATHENA.MIT.EDU (fihsu@MIT.EDU)
Mon Mar 7 00:05:24 1994
From: fihsu@MIT.EDU
To: Gilbert Leung <gleung@MIT.EDU>
Cc: resnet@MIT.EDU
In-Reply-To: Your message of Sun, 06 Mar 94 21:32:00 -0500.
Date: Mon, 07 Mar 94 00:04:52 EST
Gilbert Leung <gleung@MIT.EDU> writes:
>the root password is widely available. Having root password available on a
>public machine is neat, but not necessary. And it also creates a loophole
>for someone to have complete access to someone else's locker. Yes. Even
>now! There are not that many things worse than this. So, if you are
>concerned about security, all the root passwords on the public machines
>have be kept secret.
No, I think the Athena security is based on the presumption that
MIT users are trusted users of Athena and that the worst threats come from
the outside. Depending on how you view the students here, you may feel
that students here should not be trusted to this degree. I, however, feel
that this trust has not been betrayed for the most part. I also don't
believe that it's even practical to have a secret root password on every
public workstation.
First, any violators of Athena security issues by students of MIT can be
dealt with by MIT and penalized under our system. And considering that MIT
probably has more hackers than most if not all schools, the fact that
we've had relatively little trouble with people modifying course software,
reading through other people's email, etc. is an indicator that MIT users
can be trusted with the knowledge of the root password.
Also, most of the potential security loopholes are when the bad hacker has
access to a machine that someone "higher up" has access to. Most professors,
Athena staff, etc. who might have extra priviledges use their own private
workstations or dialup machines. Chances are that Athena staff/network
people, etc. have access to their own private dialup machines. But a
professor perhaps may want to use a regular dialup (I don't think all of
them have a private dialup machine.) These dialup machines, not being
located in public clusters, are thus harder for the bad hacker to do some
damage.
Now the problem with making the root password on public machines secret...
do you propose having a different root password for every machine? Then
record of it somewhere would have to be kept and maintained. The people
managing the Athena clusters would have to have access this information if
they knew ahead of time they might want to log in as root to have a look at
something. As for just changing the current root password to something else
for all machines.. it'd be only a matter of time before this info leaked
out. Of course, you could change it frequently enough.. but we all know
how long it takes for the new combo to the medical building to get out.
Obviously keeping any machines which allow remote access with the same
publically available root password is like dangling a bone in front of
a dog.
>Also, there are clusters like m1-115, barker-5, barker-6, that are not used
>at night at all. Also, clusters that are not close to any dorm, e.g.
>m16-034, m4 are usually quite free at night.
And the barker machines are good examples of machines that get
absolutely no usage during the night. It would be nice to at least see
machines such as these get utilization during the night hours.
Sorry for my rather disorganized thoughts.. some possible measures that
could be taken when implementing Gilbert's proposal.
1) Don't allow people to telnet to these pseudo-dialup machines from
outside of MIT. This would greatly reduce the threat of an outsider
trying to break in, and thsu make the job easier on the people who are
keeping our dialup machines secure.
2) Change the root password on machines that can become potential servers.
Perhaps have a different root password for each cluster (or in the case
of larger clusters.. each physical room) rather than individual root
passwords for every machine. A good comprimise I think...
3) Start with a small and not-so-important cluster as an initial test.
I'd like to eventually see not just a 1-user-1-machine situation for this
though.. maybe something like a maximum of 5 users per machine or something.
Or else people are going to start competing for nighttime resources.
More ideas may follow later...
Francis