[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed: task-secure-system package



On 2000-10-21 06:00, Brian May wrote:
>    Russell> No.  I like to have ssh as root enabled so that I can
>    Russell> login directly to do regular maintenance tasks with
>    Russell> minimum stuffing around.  Doing the "enter password to su
>    Russell> to root" thing works if you run one or two machines.  But
>    Russell> if you run 50 machines it's ridiculous to consider such
>    Russell> things.
>
>I happen to agree with Russell here. Or, rather, it is a compromise
>between two risks:
>
>a) that after entering your password each time, for 50 machines,
>somebody happens to observe it being entered on the 26th time, and can
>re-enter it; or you write the password down (how do you remember 50
>different passwords otherwise?). If the password is stolen (eg.
>remote system is compromised), it is much more serious if you use the
>same password for every system.
>
>b) that your private key gets stolen AND a dictionary attack reveals
>your password. (As, using ssh-agent, you only need to enter the
>password once, the points in (a) do not apply).

The real problem with B is that your colleagues may use private keys without 
pass-phrases and leave them in insecure locations where they can easily be 
stolen.
But these are the same people who write down the root password and leave it 
on their desks...

>b+c) problem here is that some
>trojan-horse-disguised-as-netscape-version-7 could automatically
>invoke "ssh -lroot remote.system rm -rf /", but I think this might be
>getting a bit paranoid. I wonder if you would be able to use
>capabilities to limit these privileges (whether ssh-agent or Kerberos
>ticket) to designated processes?

I have been considering creating a rjc-insec account with ssh setup to allow 
RSA logins from my main rjc account.  Then I could have a netscape icon spawn:
ssh rjc-index@localhost netscape

>c) accessing a remote system via an untrusted system is only a problem
>up to the expiry time on the Kerberos ticket... Just as long as you trust
>the initial kinit process with your password.
>
>I think that is a mostly unbiased representation...

Kerberos would be the best solution for large scale environments.  However 
large environments generally have crappy commercial software which makes such 
an installation difficult and expensive.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page



Reply to: