SU vs. ssh root at host

[mouring at etoh.eviladmin.org]

On Fri, 23 Feb 2001, Dan Kaminsky wrote:

> All--
> 
>     su cannot be run without trusting the shell.  The shell cannot be
> trusted without trusting any instructions the shell uses, from library calls
> to rc scripts.  Hell, the instructions the shell uses can't even be trusted,
> since they're all living in userspace memory.
> 
>     By contrast, SSHD is generally a root owned, highly secure environment
> with no unpriveledged userspace dependancies.
> 
hmm... Too many assuptions... 

>     So:  For what possible reason would I want to su to root, or any other
> account, instead of simply authenticating with the correct UID in the first
> place?
> 
>     What comes to mind is the concept that only certain users might be
> allowed to su to root, and that by forcing to users to log in as themselves,
> an accounting of *who* went to root may be done.  This seems to me an
> instance where accounting is being valued higher than authorization--a
> broken model, since a flaw in authorization will create misleading
> accounting logs.
> 
A flaw in authorization in sshd could cause a user to login without root's
password (see 2.3.1 OpenSSH bug).  

A flaw in the AES encryption could allow replay attacks like RC4.  

A flaw in a PAM module could allow a user to login with higher user
rights.

If there is a flaw in the authorization aspect of the OS.  It may not be
localized to just 'su' thus sshd provides no addition security unless it
implements it's own authorization method independant of the OS.

>     There are a couple solutions that allow us to retain such accounting,
> and do it *securely*, but I'd like to achieve some kind of consensus that
> depending on su causes root access to be dependent upon unpriveledged
> security, and is thus something to be engineered against.
> 

Hmm.. A few things you have to ask yourself.

1) Is limiting su to a smaller subset of users, and auditing su against
known attacks engineered enough to protect you?

2) What additional security risks do you take on when you allow 'root'
logins from remote (Or over localhost loopback)?

3) Is the solution worth the overhead of encryption or complex protocol
exchange?

4) If there is a fatal flaw in libc that allows 'su' to be compermised
what are the chances that the same flaw may spill over to 'sshd' (Refer
to glibc debaco recently)?  Or for that matter a function call that was
added to 'sshd' to provide platform support (refer to my f---up with
setenv().  Which luckly looks harmless outside the fact it messed up a few
platforms).

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. 

But I'm not dead sure where you are heading with this, but I perfer the
idea of 'keeping things simple' (Even if I fail to do so sometimes).  The
simplest solution with the least amount of 'edge' cases tends to win
compared to complex systems with large amounts fo 'edge' cases.  Please
note 'simplest solution' is really defined as the 'simplest correct
solution', since there are 'incorrect' solutions that are simple.=)

If you have a case which shows that 'sshd' can/will/is more secure then
'su' for the same task.  Then by all means present it.  I'm open to change
if it's in the right direction.  I think it's written into my work
contract that I need to be flexible. =)

- Ben