SU vs. ssh root at host

[mouring at etoh.eviladmin.org]

On Mon, 26 Feb 2001, Dan Kaminsky wrote:

> > 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#
> 

So.. How do I know that 'user'  was the one that stepped up to
'root'?  Are you asking me to trust the ssh client to give me a valid
username?  Are you asking me to trust the results of some 'identd'
process on a remote server?  

Na.. The latter is much more secure then the former.  I have a clear view
as to who became root and there is no remote trust level.  

> 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.)
> 

If you have 'TRUSTED' users doing such things then you should reconsider
who you allow to use 'su'.  'su' should never be accessible by any old
joe. 

Again, if you have untrusted user on a machine.  Then remove the world
read/executable and require the person to be part of the 'wheel' group or
'admin' group to run su.  

> 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.
> 

If the user can load some 'random' software that will cause authentication
to misdetect users, etc.  Then no matter what software you run there will
be a flaw.  You just remove a single method to expliot that flaw.  End of
Story.

> >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.
> 

I don't feel your solution is any better.  As stated before.

1) On a fully secure system 'root' should *NEVER* be allowed to be logged
in remotely.  This includes localhost because it's possible to spoof such
things (Granted this is my view, but it's a view that has been drilled
into me since I first started in the UNIX community in 92).

2) 'OpenSSH' portable code is roughtly 48,000 lines of code.  'su' is not
even close to that size.  Since they *BOTH* depend on the underlying
unautheration system.  Which one would you consider easier to
secure?  I'll give you a hint.  It ain't OpenSSH (Markus, no offense =).

3) Whatever solution you come up with to log the 'real user' that logged
directly into root will be a pure hack.  

Using ssh/sshd as a form of 'su replacement' is not valid.  Never will
be.  If you have clear code that shows faults in PAM or any other
authenication/logging system then your better off going to the vendors and
pushing for changes.  Any other solution is a hack.. Pure and simple.

This also has no useful bearing on OpenSSH project.  So this thread is at
at an end so useful work can be done. =)

- Ben