SU vs. ssh root at host

[Dan Kaminsky]

Ben:

    [Believe it or not, I think we're going to end up coming to a consensus
here.]

    Remote root management is a reality.  We install OpenSSH *because* we
need a secure way to manage services with significant import; while I
respect and understand the superiority of console root management, the
simple fact that servers are often colo'ed thousands of miles away in a
locked facility means Remote Root *is* going to happen.  I happen to believe
OpenSSH is *the* way to make it happen, because it's end-to-end, highly
portable, migrates elegantly, and is fast.

    But how to use OpenSSH most securely for remote root maintenance?

    When remote root is requested directly, the path of trust is
essentially:

1.  Unknown user at host1 requests root
2.  Root SSHD authenticates Root Priveledges
3.  Unknown(but authenticated) user at host1 receives root

    When remote root is requested from user shell, the path of trust is:

1.  Unknown user at host1 requests user
2.  Root SSHD authenticates User Priveledges
3.  Unknown(but authenticated) user at host1 receives user
4.  Interactive session is requested, causing all of user's rc scripts and
paths to load
5.  su is "apparently" executed, authenticating user as root.
6.  Unknown(but authenticated) user at host1 receives root.

    Of these steps, it's #4 that I have a problem with, because it's #4
that's completely outside of the control of our secure environment!  It's
like we're making every effort to do everything secure, branch out to
"whatever happens to be sitting in user-owned rc files", then swing back to
our maximum security su app.

    That can't be right!  It may win us additional accountability, but at a
cost of allowing a user-owned file to execute arbitrary commands before the
inevitable upgrade to root priveledges.

    Non-root must not be able to intercept root privileges.  HOWEVER, root
must not be accessible without non-root accountability, and if at all
possible, it's *heavily* preferable to use the operating system's existing
accounting infrastructure rather than trying to hack one together ourselves.
You're absolutely right.

    Solution, as of 27-Feb-2001:

    ssh user at host2 -t "su -l root"

    What this effectively does is eliminate step four, where arbitrary apps
are executed from the .profile/.cshrc files.  In fact, not a single variable
from the user carries over to the su execution environment--everything is
defined by our root-owned SSHD process.  We essentially restrict our trust
*from* anything the user might have wanted to execute *to* just su, which
being a setuid app can't be process traced or otherwise modified(though it
could be aborted).

    Now, this isn't perfect.  Among other things, ssh user at host2 -t "su -l"
is a painfully long phrase and is thus likely to be forgotten or mistyped.
I'm partial to adding an option such as:

    ssh -r user:root host
    or
    ssh user:root at host

    to signify that SSH should minimally authenticate against the user, then
immediate fall back to the system for su -l root authentication.  It's
effectively the "present day solution" hardcoded.  (-r stands for
re-authenticate, and is a decent opposite to -l considering -R/-L).

    There is a secondary problem, and that's that this requires us to
remember passwords!  I'd very much like *nobody* to have the root password,
and for SSH to log *which* user from the authorized_keys file logged into
root.  Is there any objection to this?  I fully grant that we lose PAM
interaction, but considering SSH's apparent desire to be free of library
interactions and the value of eliminating shared root password
awareness...might this not be the best way of all to handle situations where
multiple people require root access?

    Put simply:  Does the value of eliminating password systems exceed the
cost of losing the PAM interface?

    There's a bit more, but I'll save that for later.

    Thoughts?

Yours Truly,

    Dan Kaminsky, CISSP
    www.doxpara.com