Re: Three problems in OpenSSH's ssh-keysign

[Theo de Raadt <deraadt () cvs openbsd org>]

> 3) [Charles Hannum] The protection of host keys is not very good; to
>    wit:
>
>         key_fd[0] = open(_PATH_HOST_RSA_KEY_FILE, O_RDONLY);
>         key_fd[1] = open(_PATH_HOST_DSA_KEY_FILE, O_RDONLY);
>                         
>         seteuid(getuid());
>         setuid(getuid()); 
>
>    Although current BSD systems are safe (because they do not permit
>    PTRACE_ATTACH, et al, on processes that were ever set-id), this may
>    permit direct reading of the host keys by users on other systems.

First off, we believe that any system which has weak handling of such
setuid or setgid processes is flawed.  But let me continue before
anyone freaks out at that strong assertion.

There is a tradeoff being made here.  Either

1) We continue running as root, any exploitable bug in any code after
   that point can gain root.

or

2) We drop root, and any bug after that point can gain those file
   descriptors, and those files.

We choose 2.

That said, we very strongly believe that any system which does not
have strong de-permit semantics for ptrace and any other such calls
will continue to have serious security problems in the future.  They
force application authors to keep large monolithic processes running
entirely as root.  This is not a sustainable or safe policy.  Time for
vendors to start fixing those systems, if they are not already fixed.

This way, we do not need to keep very large applications like ssh and
sshd running as setuid root all the time like ssh.com has to.