[MacPorts] #59497: openssh @8.1p1: sshd only works in debug mode

[MacPorts]

#59497: openssh @8.1p1: sshd only works in debug mode
-------------------------+----------------------
  Reporter:  davidfavor  |      Owner:  (none)
      Type:  defect      |     Status:  reopened
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.2
Resolution:              |   Keywords:
      Port:  openssh     |
-------------------------+----------------------

Comment (by Ionic):

 Okay, here we go:

 OpenSSH already has support for the Apple sandbox, although it seems to be
 too restrictive to the latter. Hence, they patch it to include and read a
 custom-crafted profile and so do we.

 The debug mode disables any child forking, and hence also privilege
 separation, which explains why that worked.

 With privilege separation enabled, the child spawned by `sshd` chroots
 into some specific directory.

 In vanilla OpenSSH, enables the sandbox in the child process **after**
 reseeding the OpenSSL RNG and chrooting to that directory.

 However, since Apple (and we) use a special profile file, they (and we)
 enable the sandbox first, then do all the other things. It's mostly just a
 code move, but an important one, because a chrooted child couldn't ever be
 able to read the special profile file residing outside of the chroot.

 All of this has been done in exactly the same fashion for years (a decade
 or longer) and it never failed.

 I'm still clueless why it started to fail. There aren't any obvious code
 changes that would cause this (at least not within OpenSSH) and my
 experiments also didn't shed light on this.

 For instance, I essentially turned the sandbox into "transparency" mode by
 just blindly allowing everything. Didn't change a thing. I enabled
 debugging within the sandbox so that each violation would be logged. Not a
 thing.

 It doesn't look like the sandbox is prohibiting anything, but yet OpenSSL
 gets into some confused state it can't recover from once the sandbox is
 turned on. And not even that is true.

 As previously explained, the vanilla work flow is like this:
   spawn child -> do a lot of other work -> reseed -> chroot -> **enable
 sandbox**
 Contrast this to the (recently breaking) Apple-patched work flow:
   spawn child -> do a lot of other work -> **enable sandbox** -> reseed ->
 chroot

 If I modify this slightly like this:
   spawn child -> do a lot of other work -> **reseed** -> **enable
 sandbox** -> reseed -> chroot

 everything seems to work just fine.

 This doesn't make sense to me. I understand that a reseeding operation
 ''before'' enabling the sandbox works just fine... essentially because it
 also does so in vanilla OpenSSH. What I cannot wrap my head around is that
 subsequent reseeding operations also work just fine ''after'' enabling the
 sandbox.

 So, I have a workaround, but I don't want to blindly commit this to a
 security-critical package until I **really** understand what is going on.

 So far, I have only briefly skimmed the OpenSSL (not -SSH) source code and
 didn't get into the nitty-gritty details of reseeding, including fetching
 random data from the system, but it looks like I have to in order to
 understand what it's doing and why it thinks that it can't gather system
 entropy.

 To that end, I wondered whether sandboxing could change access to (already
 opened) file descriptors, but that doesn't seem to be the case. Hence,
 should OpenSSL already have an open file descriptor to, say,
 `/dev/random`, that FD shouldn't be affected by enabling the sandbox
 retrospectively. This a commonly used technique, c.f., Chromium.

 OpenSSH 8.1p1 introduced a set of more complex IPC between master and
 child processes by means of not only opening up pipes between the
 processes, but also sending some data over them. This more complex
 handling is really the only actual change from 7.9p1 to 8.1p1, but at the
 same time doesn't explain any of the things experienced.

 Further down into the rabbit hole of OpenSSL-debugging it is, then, I
 guess.

-- 
Ticket URL: <https://trac.macports.org/ticket/59497#comment:12>
MacPorts <https://www.macports.org/>
Ports system for macOS