Re: [RFC] disabled root account / distinct group for users with administrative privileges
base-passwd documents sudo as "Members of this group do not need to type their
password when using sudo", which is no longer true. I've opened a bug.
On Tue, 19 Oct 2010 at 09:48:58 +0200, Jesús M. Navarro wrote:
> On the other hand, is it really necessary a new group? Can't adm or operator
> be overloaded with this new functionality? (think Ockham's razor).
/usr/share/doc/base-passwd/users-and-groups.txt.gz documents the meanings of
the predefined groups and whether they are root-equivalent.
In particular, adm is not meant to be root-equivalent. Members can read
potentially-sensitive system logfiles, but no more:
Group adm is used for system monitoring tasks. Members of this group can
read many log files in /var/log, and can use xconsole.
Historically, /var/log was /usr/adm (and later /var/adm), thus the name of
the group.
HELP: Perhaps policy should state the purpose of this group so users may be
safely added to it, in certainty that all they'll be able to do is read
logs. Wouldn't hurt to rename it 'log' either ...
On some machines I use, sysadmins' "mere mortal" user IDs are in group adm
(so after a normal login, a sysadmin is only slightly privileged - they
can read the logs), but to actually gain root, the sysadmin must log in with a
different SSH key, which is an authorized key for a privileged user with uid 0,
named something lik smcvR.
This is to avoid having the user's "mere mortal" login already be
root-equivalent, which is inconvenient/excessive for personal machines, but
good for a server environment.
(On a machine where I can sudo, anyone who can take over my normal account can
get root next time I use sudo, by putting a trojan sudo into my $PATH and
capturing my password. On a machine where I have a separate smcvR account for
being root, I lose a bit of convenience (although not much, if I'm logging in
remotely anyway), but an attacker would have to gain control of smcvR to do
serious damage.)
Simon
Reply to: