[2250] in SIPB bug reports
xscreensaver permissions?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Mon Nov 11 03:30:29 1991
Date: Mon, 11 Nov 91 03:29:27 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: mhpower@Athena.MIT.EDU
Cc: eichin@Athena.MIT.EDU, bug-sipb@Athena.MIT.EDU
In-Reply-To: mhpower@Athena.MIT.EDU's message of Sat, 09 Nov 91 23:18:12 EST <9111100418.AA16551@m37-318-6>
From: mhpower@Athena.MIT.EDU
Date: Sat, 09 Nov 91 23:18:12 EST
It's not clear to me that there should be any setgid or setuid
programs in the sipb fileset. If I understand things correctly,
achieving such permissions in the Athena-cell copy of the fileset
requires intervention by a member of system:administrators for the
Athena cell.
The sipb-cell version of the locker is the primary, which means the
only time it will not be used as the default is when the sipb cell is
down.
Since xscreensaver will not fail completely when not installed setgid
or setuid or whatever, but rather will prompt for a password, even
when the athena cell rather than the sipb cell is used, failure is not
complete.
However, the functionality is increased by making the program setgid
or setuid or whatever whenever we *can*. I see no problem with
providing the increased functionality when we *can* provide it.
I realize that, currently, some of these persons are SIPB members, and
those that aren't SIPB members might be willing to help us out by
setting the permissions we request. In general, though, I don't think
we should rely on such requests being quickly or routinely granted
into the indefinite future. If we want an up-to-date backup copy of
the sipb fileset in a "foreign" AFS cell, I believe we should not have
setgid or setuid programs, at all. This should make software
maintenance easier, and, more importantly, place the sipb fileset more
directly under the control of (a reasonably sized subset of active)
SIPB members.
As I've said, I do not believe that the secondary copy of the locker
has to be an exact replica of the primary copy. It has to provide as
much of the functionality as is feasible, and no more. Its use is,
after all, a worst-case scenario, and it is not intended to happen
very often.
*If* the student center burns down and we find it necessary to support
the locker out of the athena cell version for a long time, and people
start to complaining about xscreensaver prompting for a password, then
we can get someone with magic bigs in the Athena cell to make it
setgid. I think we should cross that bridge when we come to it,
rather than crippling the functionality now because we can't
necessarily mirror it completely in the athena cell.
Rejecting setgid/setuid software is also of benefit to users who learn
about application programming by reading source code in sipbsrc and
trying various modifications of their own: they'll always be able to
install working versions in their own homedirs.
As I have already pointed out (and, indeed, as you pointed out as
well), xscreensaver will work without the setgid -- it will just have
to prompt for a password. Therefore, in this particular case, this is
irrelevant.
Furthermore, in the general case of setuid programs, the fact is that
there are some programs that simply need to be setuid. Ofiles comes
to mind as one of them. Yes, that's installed in the watchmaker
locker, rather than the sipb locker, but we might at some point
encounter the need or desire to support a program that requires such
privileges. I think it would be silly for us not to provide that
support simply so that users could install the programs in their home
directories.
Finally, without
setgid/setuid permissions, SIPB software could not be at fault in a
case of unauthorized privileged access to a multi-user or private
workstation.
SIPB is the most-used locker on Athena. A much larger problem than
unauthorized privileged access to multi-user or private machines is
that we could gain unauthorized access to the accounts of everyone who
uses it, through various means. Not the least of those would be
hacking xscreensaver to mail any passwords typed into it to someone,
or store them in a file somewhere or something.
The trust has already been established. If athena did not agree that
this is the case, they would not have configured the public
workstations to trust setuid in the sipb cell in the first place.
In the case of xscreensaver, I understand that there may be an minor
inconvenience if it is not setgid or setuid, but I don't think it is
intolerable. If the only problem is that encrypted passwords are not
readable on the workstation's local disk, then the user should be
specifying a password in some other manner, e.g., by using the -ekey
option or the XScreensaver.encryptedKey resource. This may motivate
some users to choose more secure passwords.
It is not our job to motivate some users to choose more secure
passwords. It is our job to provide the functionality that the users
want, where we are capable of doing so, and to attempt to provide
parallel functionality in the same programs on different platforms,
where we are capable of doing so.
Mind-games like requiring an encryptedKey resource in order to coerce
people into choosing better passwords seems to me to be both
unnecessary and beneath the SIPB.
A better solution, if acceptable to DCNS, would be to configure public
RS/6000 workstations to have more liberal permissions on all of
/etc/security, as part of the next Athena release for the RS/6000.
I have no argument with this, but it does not solve the problem *now*.
P.S., on the one RS/6000 I checked, /etc/security/passwd was mode 600,
owned by root, so perhaps setuid root would be preferable to setgid
security?
It sounds to me like the machine you checked is configured wrongly or
differently. I just checked a public RS/6000 workstation, and
/etc/security is, indeed, readable by group security.
jik
