Re: Sticky authentication/authorisation issues

["Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>]

On Thu, 2005-07-07 at 11:51 +1000, Brian May wrote:
> This also raises other issues. In fact, it is a can of worms, IMHO.
> 
> How do you get root access on the remote system via Kerberos? Do you
> log in directly as root, or do you log in as a normal user first? If
> you log in as root, do you use your standard Kerberos ticket or an
> admin ticket?

People who are authorized have Kerberos root instances; the standard
daily configuration update adds/removes these from root's .klogin as
needed.  (This also resolves potential personnel issues.)

In the case of repairing a system which failed to start sshd or where
something is wrong with it, someone would log in via Kerberized telnet
using their root instance; this way you don't risk exposing a root
password, since (it's been known to happen here) the problem might be
the machine was rooted and is running a Trojaned sshd.

> Such as if I set up Kerberos authentication or ssh public key
> authentication so I can log into several remote systems as root
> without a password, is this really a good idea? Anybody who managed to
> "grab" your console (either physically, via X, or some other way)
> would have root access to any one of the machines you have root access
> to.

You should avoid accessing such mechanisms from hosts whose security you
don't trust.  In our case, that would be machines on the Computing
Facilities subnet (and, when possible --- i.e. ssh public keys --- you
constrain their use (and, if possible, access to them) to that subnet).

There are of course limits to this; it is, as always, a tradeoff between
convenience and security, and every installation must determine how to
balance them.

> There definitely seems different tradeoffs between the different
> approaches, it concerns me that little research has been undertaken to
> work out the various tradeoffs, rather important decisions seem to be
> made on an impulse basis "we have to do it this way because if we
> don't then XYZ could occur".

I don't know of any specific research in the area, but it's a well known
issue in the Unix sysadmin community.

Balancing the costs, benefits, and potential risks of any security setup
is not a whole lot different from balancing the costs, benefits, and
potential risks of an investment.  (This is a good way to raise the
issue with management, who will likely be more familiar with the latter
than the former.)  The nature of those costs, benefits, and risks
differ, but there are enough parallels to be useful.

-- 
brandon s. allbery   [linux,solaris,freebsd,perl]      allbery@kf8nh.com
system administrator      [WAY too many hats]        allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon univ.         KF8NH