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