[MacPorts] #66358: sip-workaround no longer works on macOS 13 Ventura due to new security features

[MacPorts]

#66358: sip-workaround no longer works on macOS 13 Ventura due to new security
features
-------------------------+---------------------
  Reporter:  reneeotten  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  base        |    Version:
Resolution:              |   Keywords:  ventura
      Port:              |
-------------------------+---------------------

Comment (by neverpanic):

 The issue is in dyld. Apple has added new restrictions that depend on the
 result of a syscall called `amfi_check_dyld_policy_self()`. See

  - https://github.com/apple-oss-
 distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/dyld/DyldProcessConfig.cpp#L672-L683
  - https://github.com/apple-oss-
 distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/dyld/DyldProcessConfig.cpp#L702-L724
  - https://github.com/apple-oss-
 distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/dyld/DyldDelegates.cpp#L120-L142
  - https://github.com/apple-oss-
 distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/dyld/glue.c#L971-L977

 The only two inputs into this syscall are whether the process is
 restricted or fairPlayEncrypted. Fair Play encryption would be visible as
 a load command {{{LC_ENCRYPTION_INFO}}} or {{{LC_ENCRYPTION_INFO_64}}},
 which isn't present on the binaries in /usr/bin as far as I can see.
 Restriction is enabled if the binary has a {{{__RESTRICT,__restrict}}}
 section according to https://github.com/apple-oss-
 distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/common/MachOFile.cpp#L1588-L1598.
 A quick check in /usr/bin suggests that only the {{{fontrestore}}} binary
 has such a section, so it's also not the reason for our problems.

 However, since the system call is being performed from within the process
 in question, the kernel probably knows what binary is being executed, so
 we must also treat the process and its executable file as inputs, and I
 believe that's where the magic happens: If I try to run a copy of make, it
 is immediately killed:

 {{{
 $ cd /tmp
 $ cp /usr/bin/make make
 $ ./make
 Killed: 9
 }}}

 If I, however, remove the code signature on that binary using {{{codesign
 --remove-signature}}}, it runs and {{{DYLD_*}}} variables seem to work:

 {{{
 $ codesign --remove-signature make
 $ ./make
 make: *** No targets specified and no makefile found.  Stop.
 $ DYLD_INSERT_LIBRARIES=foo ./make
 dyld[58717]: terminating because inserted dylib 'foo' could not be loaded:
 tried: 'foo' (no such file), '/System/Volumes/Preboot/Cryptexes/OSfoo' (no
 such file), 'foo' (no such file), '/private/tmp/foo' (no such file),
 '/System/Volumes/Preboot/Cryptexes/OS/private/tmp/foo' (no such file),
 '/private/tmp/foo' (no such file)
 dyld[58717]: tried: 'foo' (no such file),
 '/System/Volumes/Preboot/Cryptexes/OSfoo' (no such file), 'foo' (no such
 file), '/private/tmp/foo' (no such file),
 '/System/Volumes/Preboot/Cryptexes/OS/private/tmp/foo' (no such file),
 '/private/tmp/foo' (no such file)
 Abort trap: 6
 }}}

 It seems to me we need to modify {{{sip_copy_proc}}} to strip Apple's
 signature from those binaries.
 Signing the binaries with an ad-hoc signature also seems to work, but
 that's probably a lot more complicated to implement (although we may have
 to for arm64).

 Additionally, those binaries use the arm64e architecture, so we'll
 probably also have to start building an arm64e slice of darwintrace.dylib.

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