[2532] in SIPB-AFS-requests

home help back first fref pref prev next nref lref last post

Re: fun with pts

daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Tue Oct 29 01:30:32 1996

From: mhpower@MIT.EDU
Date: Tue, 29 Oct 1996 01:30:23 -0500
To: warlord@MIT.EDU
Cc: marc@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[2529] in SIPB-AFS-requests"

>The problem with system:authuser is that it requires a system
>administrator to add users to the pts database.

Yes, I know the difference.

In a world in which we had copious free time to write new code, these
additions might be made by some server that obtained tokens for
rcmd.ronald-ann, after checking that the requested addition was for a
principal that ought to be allowed to access MIT-only software. The
authorization policy would presumably disallow principals that have
published passwords, and might also disallow some other principals
(perhaps certain types of guest accounts or test accounts).

In other words, it doesn't necessarily require human intervention,
although in practice we may end up running it that way.

>          ... system:authuser@athena.mit.edu, allows *ANY* athena user
>to add themselves to the database ...

I think having this on acls for some types of MIT-only software would
be wrong, mainly because of the history of access in the athena cell.
A few years ago, running MIT-only software from the athena cell only
required system:authuser access. Later, it became necessary to use
unwrap -- I think there were a variety of reasons for this, but the
fact that some athena Kerberos passwords were very widely known
outside MIT was one reason (admittedly not the primary reason).

If SIPB decided to use system:authuser@athena.mit.edu as the only
access restriction for all types of MIT-only software, someone
responsible for MIT's software licenses might eventually become
annoyed by this and cause various Bad Things to happen to SIPB.

On the other hand, if SIPB continues to restrict to system:authuser
(in the sipb cell) in relevant cases, that might be seen as a more
prudent way of trying to prevent non-MIT use. In other words, the
absence of well-known-password principals that have system:authuser
access in the sipb cell may provide enough incremental security that
our system:authuser is deemed sufficient whereas the athena cell's
system:authuser is not.

Matt

home help back first fref pref prev next nref lref last post