[885] in athena10
Re: [athena10] sudo
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jan 22 11:44:23 2009
From: Greg Hudson <ghudson@MIT.EDU>
To: Evan Broder <broder@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <4977F898.7010500@mit.edu>
Content-Type: text/plain
Date: Thu, 22 Jan 2009 11:43:25 -0500
Message-Id: <1232642605.6528.4.camel@ray>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Summarizing discussion on zephyr and adding one of my own concerns:
1. You don't have to convince me, but I'm not certain it's wise to give
cluster users sudo access. To me, it crosses the line between allowing
root and unwisely encouraging it. Also, if the login chroot is out of
date (as will happen frequently on a transient basis) it will cause the
update manager icon to appear in the notification area, which to a naive
user is confusing noise.
(I understand the counterargument, which is that this makes it easier
for people to install additional Debian software in the login chroot.
That may be compelling enough to ignore my concerns.)
2. Passwordless sudo means you can get root (within a login chroot) if
you take over the console session of another user, e.g. if someone
leaves their session un-screensaved. It's not clear whether root access
within a login chroot is more valuable to an attacker than a user's
tickets and tokens are.
On Wed, 2009-01-21 at 23:39 -0500, Evan Broder wrote:
> Ok - I know how to give people sudo bits now (for the curious, it
> involves a change to /etc/pam.d/gdm, /etc/security/group.conf, and
> /etc/sudoers).
>
> I'm stumbling over exactly what these bits should look like. The
> specific mechanism I've come up with only gives sudo bits if you login
> at the console, and only on cluster machines (well, the latter more or
> less applies the former, since it's not easy to login from
> not-the-console on cluster machines).
>
> Given this, what do people think about allowing password-less sudo? It
> seems potentially reasonable given those constraints.
>
> - Evan
