Re: Sticky authentication/authorisation issues

[Brian May <bam@snoopy.apana.org.au>]

note: changed subject

>>>>> "Brandon" == Brandon S Allbery KF8NH <allbery@ece.cmu.edu> writes:

    Brandon> On Thu, 2005-07-07 at 09:20 +1000, Brian May wrote:
    >> Is there anything you can do in telnet that you can't do in
    >> ssh?

    Brandon> Recover when sshd is hosed / not running.  Backup access
    Brandon> mechanisms matter.

Good point. Just been in a situation recently where somebody upgraded
ssh on a remote server and accidently turned off password
authentication. It become difficult to log in again and fix the
problem.

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?

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.

SE-Linux people have the approach that they don't trust ssh. It could
still have root exploits that haven't been discovered. After logging
in as root, you have to enter the root password again before you get
root privileges. Once logged in, if you want to do an action
considered "unsafe" (e.g. start/stop daemons), you are required to
enter the root password again. This prevents a Trojan from doing the
unsafe action without you knowing about it. (What happens if the
password prompt is a Trojan?)

I counter argue that this somewhat defeats the purpose of
single-sign-on, and maximises the number of times you need to enter
the password and the chances of being observed entering it. It also
maximises the chances of entering the wrong password on the wrong
computer (and having that grabbed too). Also if ssh really is
compromised, it could grab the password you repeatedly enter anyway.

The other approach is taken by sudo people, including Ubuntu, where
the single password will give you access to both the users account and
root. So if you see somebody enter their non-root password you can
gain root access too, even if the user never wanted root access for
the session.

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

Comments anyone?
-- 
Brian May <bam@snoopy.apana.org.au>