[tlug] on root logins (1)

["Stephen J. Turnbull" <stephen@example.com>]

Jim Jepson requests that I clarify the seeming oxymoron "anonymous
root login".

>>>>> "sjt" == Stephen J Turnbull <stephen@example.com> writes:

    sjt> In cases where "security" has the semantics of "identify all
    sjt> users" [setting the root password is] simply wrong, since it
    sjt> permits anonymous root logins.

There are two kinds of identity here, the account (user id) and the
user (human).  In most cases on personal workstations, root is an
alias for the usual user.  However, in an organizational context,
typically root is a shared account, used by several members of an
administrator team.  Thus, if "root" does something, you can only pin
it down to one of several persons, and in that sense it's anonymous.
If the "something" is mischievous or destructive, everybody has
plausible deniability (including for inadvertant leaks of the
password), and everyone has somewhere between a little and a lot of
incentive to hide behind that, depending on how punitive the
organization (or external authorities like the police) are minded to
be.

Programs like su and sudo[1], although they work very differently, log
the real uid of the user who is exercising root privileges.  Sometimes
to syslog or messages, sometimes to auth.log or something like that.
You might think that this doesn't matter---root can change the logs,
no?---but in fact in a high-security environment (copies of) the logs
will be written to write-only media on a different host.

Thus, in a team environment, accountability suggests that each member
should authenticate as themselves to a personal account, and access
authorized privileges from that account via su/sudo rather than a
shared account such as root.

Note that even if you su to a shell, it may be possible to trace which
instance of the root user executed various programs, but it's probably
hard to do so.  Thus sudo provides the most accountability.

Footnotes: 
[1]  The super(1) man page doesn't mention logging, and the program
itself allows all kinds of dangerous practices.  I don't think I can
recommend that one.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.