[19592] in Athena Bugs
access_on documentation bugs, security concerns
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Sat Aug 11 03:56:57 2001
Message-Id: <200108110756.DAA01173@Press-Your-Luck.mit.edu>
To: bugs@MIT.EDU, ostock@MIT.EDU
Date: Sat, 11 Aug 2001 03:56:55 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
1.) Documentation doesn't match experience
http://web/answers/accounts/accounts_copy.html
is about how to copy files between two Athena workstations.
> IV. Have a private transfer on one workstation:
>
> 1. Have your friend type 'access_on' so you can log into your
> friend's machine as follows:
>
> ssh machine
> or telnet machine
>
> Once you are successfully logged in, he can type 'access_off' to
> prohibit others from logging in remotely.
If I'm not mistaken, I confirmed with Athena 9.0 in the test cluster a
while back that "ssh machine" won't actually work on public Athena
machines, because they are not configured to run sshd by default. I
personally I don't understand why not.
Also note that
http://web.mit.edu/answers/solaris/solaris_single_user.html
claims that access_on does not work for Solaris machines because they
are only licensed for single-user use. It does, in fact, work, but
I'm not sure whether the license has been changed to allow this.
2.) Security concerns
Typing "access_on" is actually more dangerous than this answer leads
one to believe. If I'm a mischievous student sitting at a nearby
machine, and I happen to overhear a conversation between two people
who are copying files in this manner, I can telnet in when one of them
types access_on. Unfortunately, on a public workstation, the root
password is freely available. I can then become root and steal their
Kerberos tickets off the local disk. I then have all of the
privileges of their Athena account for the next ten hours or so.
Perhaps the risk of this happening is low, but it is probably a bad
idea to keep users in the dark about that sort of risk, lest they be
careless in typing access_off promptly.
Potential solutions:
- Rewrite access_on to take a username (or machine name, though that
seems less secure) as an argument, and only allow logins from that
trusted party.
- Leave access_on like it is, but fully inform users as to the risks,
and suggest alternatives. (In fact, several alternative methods
for file sharing are already mentioned in this answer.)
- Remove access_on and make it hard for multiple users to log into a
public workstation. (Perhaps bad if say, two people are
collaborating on a project and they both want to run software on
platform A, but the second person must log in on platform B because
the cluster is crowded. Or if they want to work together on a
large data set which is most convenient to store on a single
machine.)
- Enhance the warning message that root logins generate, so that if
someone is sshing in as root, for example, or someone who is ssh'd
in su's, the message includes the host they are coming from, and
perhaps their real username, if retrievable, and a little note
saying that the user better hope this person is not stealing their
identity.
- Disallow root logins from anyone other than users physically at the
computer.
- Enhance multi-user security on public machines so this sort of
identity theft isn't possible. (Not likely any time soon.)
3.) And then...
If ssh access were enabled in an acceptably secure fashion, another
useful tidbit to include in this answer would probably be that "scp"
can be used to securely transfer files between workstations. This is
very useful for large files that must be stored on local disk because
they are larger than the available space in any user's personal
volume.
