[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 jrabinow):

 {{{
 macOS 13.3 22E252 arm64
 Xcode 14.3 14E222b
 }}}

 As far as I can tell, `amfi_check_dyld_policy_self` isn't being issued as
 per
 - /usr/bin/syscallbypid.d
 - /usr/bin/syscallbyproc.d
 - /usr/bin/syscallbysysc.d
 and no new process is being executed as per `/usr/bin/newproc.d`.
 `execsnoop` does see `make` but when I tried tracing it with `dtruss -W` I
 got `failed to grab pid 19387: (null)` which makes me think it's too
 short-lived and/or doesn't get initalized properly. So somewhere between
 execsnoop and newproc.d the process gets killed off.

 -----------------
 I tried to strip the signature from make as described above, it's still
 getting killed:
 {{{
 $ codesign --remove-signature make
 $ codesign -vv make
 make: code object is not signed at all
 In architecture: arm64e
 [Exit 1]
 $ ./make
 Killed: 9
 [Exit 137 (KILL)]
 }}}

 I also tried signing make with my own custom signature and it still didn't
 launch.
 ----------------------

 Moving onto provenance:
 I can see the provenance on make. Worth noting it didn't appear
 immediately (less than 1h of playing around with it, digging into this and
 a few other things). When I tried checking and copying a `make2` to tmp,
 the provenance appeared right away though, so go figure if I didn't mess
 up somehow.
 {{{
 $ /bin/ls -l@ /tmp/make
 -rwxr-xr-x@ 1 julien  wheel  132017 Jul  4 16:09 /tmp/make
         com.apple.provenance        11
 $ xattr -px com.apple.provenance ./make
 01 00 00 5D 19 F7 5D 19 6C 9E A9
 }}}
 From: https://eclecticlight.co/2023/03/13/ventura-has-changed-app-
 quarantine-with-a-new-xattr/
 `The xattr is protected by SIP, so can’t be removed unless the app is
 copied to another volume.` I haven't tried removing it.

 Also for what it's worth, I asked chatgpt for a summary of what are
 cdhashes and checked it against apple's docs (links below). It had this to
 say:
 {{{
 A CDHash, short for Code Directory Hash, is a cryptographic hash value
 associated with a binary executable file on macOS systems. It is used as a
 security measure to verify the integrity and authenticity of the code
 before it is executed.

 When a binary is signed with an Apple Developer certificate, the signing
 process generates a CDHash for the code. This hash is derived from the
 code directory, which contains a list of the file offsets and sizes for
 each segment of the executable. By calculating the CDHash, the system can
 ensure that the code has not been tampered with or modified since it was
 signed.

 The CDHash is stored in the code signature of the binary and is checked by
 the Gatekeeper service on macOS when an application is launched. If the
 CDHash does not match the expected value, indicating that the binary has
 been altered, Gatekeeper will prevent the application from running,
 providing an additional layer of security against malicious software.

 It's worth noting that the CDHash is just one component of the code
 signing process on macOS, which includes other checks.
 }}}
 Also see:
 -
 https://developer.apple.com/documentation/endpointsecurity/es_process_t/3228976-cdhash
 - https://developer.apple.com/documentation/technotes/tn3126-inside-code-
 signing-hashes

 If this is what is causing issues, I'd assume the following approximate
 setup:
 - the provenance is stored in the binary's extended attributes and can't
 be removed because SIP.
 - this provenance points to an entry in the ExecPolicy database in
 provenance_tracking table. I tried finding it but couldn't.
 - The execpolicy database would allow the OS (going by opensnoop's output,
 most likely syspolicyd) to compare the calculated cdhash against the
 cdhash stored in the provenance_tracking table.
 - The cdhash is used to seal the binary. If the calculated values don't
 match the cdhash, the OS (again, most likely syspolicyd) sends kill -9

 Worth noting that I tried finding make in
 /var/db/SystemPolicyConfiguration/ExecPolicy provenance_tracking table but
 couldn't find anything that seemed relevant. I rebooted my computer in
 case the db was only flushed to disk on process restart, still no dice. I
 didn't see anything relating to /usr/bin in there either, so I'm still
 missing something and I'm not sure if this ExecPolicy database is
 relevant. Maybe provenance is used by something else? Maybe, as chatgpt
 suggests, it's another mechanism entirely?

 I'd suggest the way forward on this one would be to open up execsnoop
 script, repurpose it to have it attach to a new process named `make`,
 `gatekeeper` (assuming it runs in its own process) or `syspolicyd` and
 have it observe everything that happens to it. I've barely looked at
 gatekeeper, and https://eclecticlight.co/2023/03/16/what-is-macos-ventura-
 doing-tracking-provenance/ suggests to me that gatekeeper might run even
 before syspolicyd gets involved at all.

 Also I'd be curious if anyone can repro the copying of a binary out of
 /usr/bin without the 'provenance' xattr, like I initially got and like
 kencu's comment above suggests. Can make run at that time? If you wait for
 some time, does the provenance appear on its own? If so, does the binary
 start getting killed then?

 Question from a complete newbie, why do we need to use Apple's binaries at
 all? Could macports not ship its own binaries and bootstrap from there,
 reminescent of the gcc bootstrapping process?

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