[OmniOS-discuss] OmniOS Bloody update

[Alex Wilson]

> Jim Klimov <jimklimov at cos.ru> wrote:
> 
> Is there some defimitive list of functional difference between OpenSSH
> vanilla and SunSSH as of today (given the latter started as a fork of the
> former, IIRC)? Am I wrong to think the benefits of SunSSH revolved around
> integration with Solaris security features like RBAC and PAM? Was there
> more to it? Why is it hard to upstream and just get the common (or
> specially ifdef'ed) OPENSSH to become SUNSSH + more new features/bugfixes,
> and not maintain and reconcile two forks?

I can give you a list of the features that Sun added in SunSSH which were
never upstreamed in to OpenSSH, and then also the features that OpenSSH have
removed upstream which were still in SunSSH. Between the two of these you
should be able to get a list of all the currently known expected differences
between the two.

Big ticket items added in SunSSH:

 * Support for Solaris PAM -- our PAM actually has some not-so-subtle
   differences to Linux PAM, and there are bugs in Linux PAM that
   openssh-portable has workarounds for which actively cause problems if
   used on our PAM. This is the root cause of all of the role/RBAC issues
   when using OpenSSH on Illumos.

 * Separate PAM facilities for each auth method (eg pubkey,
   keyboard-interactive etc)

 * Support for GSS KEx and the Solaris Kerberos -- once again our krb5 is
   slightly different to everyone else and the patches to make this work are
   important to some users.

 * Support for BSM audit -- makes system-wide login event reporting
   consistent

 * i18n/gettext support -- SunSSH is fully translatable with gettext (though
   in Illumos no translations are available in the gate)

 * Language and locale negotiation -- this uses the protocol provisions for
   language negotiation to set up the LANG and LC_* env vars on the remote
   machine to as closely match the client's settings as possible based on
   the locales and languages available on the server. This is not the same
   as just using "SendEnv" and "AcceptEnv" (but those do likely cover 90% of
   real use of this feature)

 * altprivsep (Sun's alternative privilege separation model) -- I'm not
   going to try to explain this in detail, but the README.altprivsep file in
   the gate has a lot of text about it. Note that the text doesn't really
   line up 100% with what the code actually does, and I personally think the
   altprivsep model is badly broken (hence I did not attempt to port it
   forwards in the patches Joyent are working on)

 * Dropping Illumos fine-grained privileges in ssh-agent and the daemon --
   this sounds small but I consider it a big-ticket item. We've had support
   for fine-grained privileges in the vein of OpenBSD's tame(2) for a long
   time, and they are a powerful way to help reduce the impact of security
   bugs in critical daemons like SSH.

Smaller things in SunSSH:

 * -Y and -X -- SunSSH's -X option acts like -Y does for the rest of the world

 * Support for some additional key formats (RFC4716, PKCS8)

 * Extra hooks / plugins: PreUserauthHook, PubKeyPlugin

 * Support for dtrace in places, including the sftp-server which has special
   probes for performance measurement

 * Bug fixes for users with non-default login privilege sets (eg not
   checking the inability to setuid back to root after changing) and users
   on auto-mounted NFS home dirs

 * man pages reorganised into Illumos numbering

 * CTF information in the SSH binaries

 * Workarounds for earlier SunSSH bugs so that S10-era SunSSH clients can
   connect to a SunSSH daemon (even though they would, in some
   circumstances, fail to connect to a stock OpenSSH server). I hope this
   one has been unused for a long time.

Things removed or changed significantly in OpenSSH (as of 7.1p1):

 * DSA keys are disabled by default for pubkey auth

 * tcpwrappers have been removed

 * Support for dh-group1 keyex has been disabled by default (so a brand new
   OpenSSH daemon and an old SunSSH client have no keyex algos in common and
   cannot connect)

 * Key fingerprint formats: default key fingerprint format is now ALG:base64
   rather than the old MD5 hex format.

A number of these changes have had attempts to upstream them over the years,
but most of them have been rejected. Especially with respect to the PAM
issues, it's not clear that there is an easy way to have a single C file
that is compatible with both our PAM and the Linux PAM without it having so
many #ifdefs as to be unreadable. Similar story with KRB5.

Some patches are just simply not suitable for upstreaming -- dtrace changes,
man page renumbering, CTF information, restoring tcpwrappers support,
gettext/i18n code -- none of these things are things that the upstream
OpenSSH developers have shown any interest in or desire to take on (and have
actively dismissed attempts to do so in the past)

In other cases, patches have been rejected upstream because of past lack of
time/effort on Oracle or Sun's part to take feedback from OpenSSH developers
into account, or various semi-political concerns. I'd like to revisit some
of these in the near future.

Hope that helps explain things. The patching effort I've been going through
at Joyent is to aimed at creating an up to date OpenSSH that is as
compatible as reasonably possible with SunSSH, to make the transition smooth
for the majority of our users. Then I will proceed to try to slowly upstream
or deprecate and drop as many of the changes as possible to get us closer to
plain OpenSSH. It's likely that some of the patches will be carried by us
indefinitely, however, which is not unexpected.

As an aside, I don't think there is a major Linux distro or BSD (aside from
OpenBSD, of course) out there that runs an unpatched stock OpenSSH by
default with the upstream default config. The fact is that everybody has
local patches they carry around on the SSH code, or at the very least a
non-stock default config file for the daemon they provide. Debian, for
example, carry around about 40 patches to OpenSSH locally, with a total line
count comparable to the current revision of the Joyent patch stack.