# [OmniOS-discuss] OmniOS Bloody update

Alex Wilson alex at cooperi.net
Thu Sep 17 18:53:23 UTC 2015

- Previous message: [OmniOS-discuss] OmniOS Bloody update
- Next message: [OmniOS-discuss] OmniOS r151014 update - needs reboot!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

- Previous message: [OmniOS-discuss] OmniOS Bloody update
- Next message: [OmniOS-discuss] OmniOS r151014 update - needs reboot!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list