SU vs. ssh root at host

[Dan Kaminsky]

> Personally, I don't think the use of 'sshd' as a form of local
> authentication is really any more secure then a well written 'su' on a
> good solid audited OS.  Once a cracker with half a brain has compermised
> your system (via su, sshd, etc) you'll never see the log files unless you
> are doing remote logging.

This is when Dan slaps his forehead and says, "Oops."

I'm *not* talking about:

user at host1$ ssh root at 127.0.0.1
root at host1#

I'm talking about:

user at host1$ ssh root at host2
root at host2#

Being *far* superior to:

user at host1$ ssh user at host2
user at host2$ su root
root at host2#

Because there's no reason to actually believe user at host2 will actually
execute /bin/su, not log characters, or whatnot.  There's no way to know if
.profile actually contained an app called hacksh, which was entirely adept
at hiding its own existence through userspace(after all, all you know about
a remote host is what it sends you--there's nothing to prevent a passthrough
like hacksh starting up in .profile, hiding its existence from within
itself, and preventing attempts to blindly clear it.)

I argue, when connecting to a remote host, one should authenticate
*directly* against the account one wishes to connect to.  That way, only the
trusted *root* process is receiving authentication material, as opposed to
any random software that the user might have configured to load on startup.

>From a purely theoretical point of view, it's better to *lose* permissions
than *gain* them, because exploits don't generally *reduce* access to
systems--they seek to *increase* functionality by any means necessary.

I'm hacking on technical solutions to solve the accounting problem(per-user
root accounting becomes harder when everyone's going straight to root, but
ssh has a number of appropriate systems to handle this), but I want to get
some kind of consensus first that engineering out the need for su is
worthwhile.

Thoughts?

Yours Truly,

    Dan Kaminsky, CISSP
    www.doxpara.com