Verification fails for some applications

[blochberger]

simbple fails to verify the sandbox profiles of the following apps (tested on macOS Catalina 10.15.3):

Applications in /Applications:

• Avira Security
• Houseparty
• Microsoft Word, Excel, and PowerPoint (fixed with 710e695)
• Safari (fixed with 710e695)

Applications in /System/Applications:

• App Store (fixed with 710e695)
• Books (fixed with 710e695)

Note that Safari and the Microsoft apps have the com.apple.security.temporary-exception.sbpl entitlement. Not sure whether this is related, but struck me as suspicious.

[0xbf00]

Thanks for reporting! I can reproduce the issue with Safari on 10.14.6. I will not get around to fix this anytime soon though. Happy to take pull requests though ;-)

[0xbf00]

There are probably a number of issues at play here. One of them is that simbple still doesn't properly handle raw strings. I thought I had fixed this, but this is why Safari's sandbox profile on 10.14.6 cannot be verified. I have developed a fix locally and will push the changes in the next couple of days. I suspect that there are additional problems on macOS Catalina. One possibility is that one of the initialisation files embedded in libsandbox.1.dylib changed with one of the recent updates.

[0xbf00]

Houseparty.app is puzzling to me. Verification works on 10.14.6 but does not on 10.15.3. I’ll update to 10.15.4 later and see if that changes things.

In case this problem is related to entitlements processing, you can debug the issue by iteratively removing entitlements from the app (by resigning the app) and then repeating the verification process after launching the app once.

I did this and was able to eventually identify the entitlements triggering the issue:

% diff houseparty.entitlements houseparty.entitlements.original
8a9,14
> 	<key>com.apple.developer.team-identifier</key>
> 	<string>WNNZ933TRG</string>
> 	<key>com.apple.developer.aps-environment</key>
> 	<string>production</string>
> 	<key>com.apple.application-identifier</key>
> 	<string>WNNZ933TRG.com.herzick.mac</string>

With these three entitlements removed, the app can be verified. Unfortunately, I wasn’t able to nail down the issue further because as soon as you specify one of these entitlements without actually having a legitimate dev cert, your app is getting killed by the OS.

Nevertheless, this behaviour is actually quite strange: Safari.app has two of these entitlements and can be verified. The only entitlement missing from Safari that is present here is the .team-identifier entitlement. None of these entitlements are however ever referenced during profile generation and they are not part of any sandbox snippets on my system, which means they /should/ have no effect on the resulting sandbox profile.

To me, this leaves the following root causes:

• Starting with 10.15.x, some of the parameters necessary to replicate the sandbox profile are not persisted by AppSandbox.framework. This would mean there are more entitlements / rules given to libsandbox.1.dylib for compilation.
• I just cannot find the SBPL responsible for processing the team-identifier entitlement.
• There is a bug in libsandbox.1.dylib on 10.15 that affects this app (what other apps cannot be verified currently?)

[0xbf00]

macOS 10.15.4 seems to change a number of things (see also linked Milestone) that impact simbple negatively right now. Until they are addressed, simbple should only be used on earlier versions.

[0xbf00]

I've now made changes to support 10.15.4. Interestingly, Houseparty.app and Avira Security can be verified on 10.15.4.

I spent considerable amounts of time figuring out what went wrong on 10.15.3 and all I could figure out is that the final line in the application.sb profile seemed to be the culprit. Official profiles on 10.15.3 were missing the rules that are protecting the redirectable paths. Back in 2018, I had a similar problem and wrote:

In unusual cases, a (very low) number of rules present in the generated profile were missing from the ground truth. Unfortunately, it was not possible to identify the root cause here. At this point, due to this happening only in rare cases and for no readily apparent reason, this behaviour is likely either a bug in Apple’s implementation or an optimisation. If it is a bug, the re-computed result is – in some sense – more correct than the original result. If it is an optimisation and affected rules are redundant, retaining them does not change semantics.

The problem does not occur on 10.15.4 and 10.14.6. As such, I think this was a bug in Apple's implementation.

[0xbf00]

@blochberger Please test all apps on 10.15.4 and close this issue if the updated versions works for you.

[blochberger]

I can confirm that Houseparty and Avira Security can be verified with 10.15.4. However, some other apps cannot:

• Telegram Lite
• Microsoft Word (version 16.37 works on 10.15.3 but not on 10.15.4)
• magentaCLOUD

[0xbf00]

The issue here is the same as with Houseparty.app and Avira Security.app on 10.15.3. As I said in a previous comment, my comment from 2018 still stands. This is either a possibly incorrect optimisation or a bug on Apple's side. Because this happens only to a few apps and the apps to which this happens tend to change in between point releases, my best guess would be that libsandbox somehow triggers undefined behaviour here.

Either way, it is a rabbit hole which I will not go down any further. If you want to generate profiles that can be verified in these cases, you can use a slightly modified profile:

$ wc -l /System/Library/Sandbox/Profiles/application.sb 
    1527 /System/Library/Sandbox/Profiles/application.sb
# Replace 1526 with result of previous command - 1 on your system to remove last sandbox rule.
$ head -n 1526 /System/Library/Sandbox/Profiles/application.sb > temp_profile.sb
# Verification should succeed now
$ ./simbple ~/Library/Containers/to_verify --profile temp_profile.sb --verify

Is this bug a security issue in libsandbox? Perhaps, though you'd need to spend more time to figure out what is happening here. Why are only these apps affected? Are the rules even used at runtime or are they entirely redundant? Is it just a strange optimisation on Apple's part?