Re: Considering shipping ssh-keysign non-setuid

I'm pretty sure that would be a mistake.

The problem is not ssh-keysign.

It is a kernel bug.

It affects any setuid program and it is my understanding that a typical
Linux ships with almost a hundred of those.

It is also my understanding that this bug (set of bugs really) does not
just affect setuid binaries, but is already being extended to create other
artifacts.

> In light of things like
> https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn and the general
> attack surface of set-id, I'm considering changing Debian's OpenSSH
> packaging to ship ssh-keysign non-setuid, and patching the
> documentation to tell users that they need to make it setuid root
> (using a Debian-specific tool that causes that kind of change to be
> preserved across upgrades) if they want to use host-based
> authentication.  My sense is that host-based authentication is quite
> niche these days and that it already involves a certain amount of
> specialized setup anyway.
> 
> As far as upgrade considerations go, ssh-keysign is client-side, so
> there should be no risk of making people's machines inaccessible on
> upgrade.  We could possibly detect whether `EnableSSHKeysign yes` is
> already set in the client configuration and preserve the setuid bit in
> that case.
> 
> Would the upstream developers have any objection to this
> configuration?  It would be a difference from what `make install` does
> and it's possible that it might result in the odd stray support
> request, so it seemed polite to check.
> 
> Alternatively (or additionally), I'm considering splitting ssh-keysign
> out to a separate `openssh-keysign` package, since most users don't
> need to have it installed at all.
> 
> It looks as though Fedora does both these things (a separate package,
> and no setuid bit).  They seem to have no documentation of how to make
> ssh-keysign persistently setuid on systems that require it, at least
> not in their packaging.
> 
> Thanks,
> 
> -- 
> Colin Watson (he/him)                              [[email protected]]
> _______________________________________________
> openssh-unix-dev mailing list
> [email protected]
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev