Add a Bundle ID rule type ?

[np5]

Type: BUNDLEID
Identifier: TEAM_ID:BUNDLE_ID (43AQ936H96:org.mozilla.firefoxdeveloperedition)

Pros:

• Be able to target all versions of an application
• All the information to make the decision is already in the SNTFileInfo
• No need to change the sync protocol

[arubdesu]

I'd chime in to add that while this idea is prescriptive by spelling out the expected implementation detail/contents of a rule, it's somewhat intuitive that precedence-wise, we're placing bundle above a binary and below the same-tier-y teamIDs and certificates (which are all in turn below regex scopes). I personally agree with the implementation being teamID-focused since it's the new hotness (and deservedly so) vs. certs, as they conceptually eclipse previous cert rules' utility.
As far as I understand it, for sync servers there are also the tasks of correlating and providing an interface where admins can understand how binaries are considered under the umbrella of this rule type/the bundle ID in question.

[pmarkowsky]

I'll admit I like this idea. As it'd let you easily allow list an entire bundle while still blocking a TeamID.

In this new scheme then the rule precedence from highest to lowest should go as follows with our first match:

graph TD
    A[SHA256 Rules] --> B[Cert Rules]
    B-->C[Bundle ID Rules]
    C-->D[Team ID Rules]
    D-->E[Path Based Rules]

[russellhancox]

Hmm that's true. In theory they sit at the same level but the perf. advantage does put that first. But then bundle ID (if we manage to do it) would go above cert rules as it's more specific than a cert.

[pmarkowsky]

I guess I was assuming cert rules were more specific than bundle and teamID since both would be shared across multiple versions of apps that are signed by different certs.

[russellhancox]

A cert is more specific than a team ID but a bundle is one thing signed by that developer. While a given bundle might be signed by multiple certs over its lifetime, I'd argue that a bundle is more specific than a cert which can sign multiple apps.

[pmarkowsky]

OK, I'm convinced. So we need to the following precedence:

graph TD
    A[CDHASH Rules] -->B[SHA256 Rules]
    B[SHA256 Rules] --> C[Bundle ID Rules]
    C-->D[Cert Rules]
    D-->E[Team ID Rules]
    E-->F[Path Based Rules]

[russellhancox]

👍

[russellhancox]

I like this idea generally but I don't think there's a way it can be done that is performant and safe. The existing implementation of bundles utilizes a helper process that scans the filesystem using heuristics to determine the "main" bundle for a given executable - this process can be quite slow (think Xcode.app, which is ~17G uncompressed and has >500k files) - and then determines all the binaries inside. It's OK that this takes a while because it is done outside of execution time (we only do it once execution has already been denied and the GUI is showing)

To elaborate, using Firefox as the example:

Firefox.app contains a helper process Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container. When this executes, how do we determine that it is part of the org.mozilla.firefox bundle? We know the team ID from its code signature but the bundle ID is not part of that. Walking up the filesystem the "nearest" bundle is plugin-container.app but that has the bundle ID org.mozilla.plugincontainer - do we continue walking? In order to tie the plugin-container binary to the org.mozilla.firefox bundle we'd have to walk up 4 folders and parse the content of two Info.plist files.

[russellhancox]

Not only is that process of walking and reading slow, we can't rely on the contents of the Info.plist without doing a full signature verification of the containing bundle to know that the Info.plist hasn't been tampered with; this can be very slow, running codesign -dv on Xcode.app can take multiple seconds.

[tburgin]

What if instead of using a bundle id we used a code signing requirement? This would allow for more flexibility and sidesteps the need for us to walk up the bundle tree. The requirements would still be prefixed by a team id.

A set of code signing requirement rules are provided by the admin which are indexed by the team id. When evaluating a signed executable all of the code signing requirements are looked up for the team id. Each code signing requirement is then evaluated against the executable's code signature.

Using Firefox as an example: (identifier "org.mozilla.firefox" or identifier "org.mozilla.plugincontainer"). This shifts the work of discovering which identifiers should be used to the admin and frees Santa from trying to discover what the root bundle id would be.

% codesign -vv -R='(identifier "org.mozilla.firefox" or identifier "org.mozilla.plugincontainer")' 
/Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container: explicit requirement satisfied
% codesign -vv -R='(identifier "org.mozilla.firefox" or identifier "org.mozilla.plugincontainer")' /Applications/Firefox.app/
/Applications/Firefox.app/: explicit requirement satisfied

The requirement is very prescriptive. See how leaving out org.mozilla.crashreporter (or another way for it to pass) causes a failure.

codesign -vv -R='(identifier "org.mozilla.firefox" or identifier "org.mozilla.plugincontainer")' /Applications/Firefox.app/Contents/MacOS/crashreporter.app
test-requirement: code failed to satisfy specified code requirement(s)

Of course the more requirements added per team id the slower evaluation will be. We could maybe find another "known" attribute in addition to team id for additional sharding.

I need to do some performance tests of code signing requirement evaluations to see if this is at all a viable option.

This opens up the possibility of bundle ids, but also anything else that can be expressed in a code signing requirement. If performant this could be very powerful.

[pmarkowsky]

@mlw pointed out in chat the EndpointSecurity.Framework passes the signing_id field that's equivalent to the identifier.

He's also stated which is often the bundle ID, but not required to be that.

[pmarkowsky]

Signing ID rules have been added to Santa as of #956 and should be available for use in the 2023.5 release.

Rules will have the following precedence.

graph LR
    A[SHA256 Rules] --> B[Signing ID Rules]
    B-->C[Cert Hash Rules]
    C-->D[Team ID Rules]
    D-->E[Path Based Rules]