Replies: 5 comments 9 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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]
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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]
|
Beta Was this translation helpful? Give feedback.
-
|
👍 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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: The requirement is very prescriptive. See how leaving out 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. |
Beta Was this translation helpful? Give feedback.
-
|
@mlw pointed out in chat the EndpointSecurity.Framework passes the He's also stated which is often the bundle ID, but not required to be that. |
Beta Was this translation helpful? Give feedback.
-
|
Signing ID rules have been added to Santa as of #956 and should be available for use in the 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]
|
Beta Was this translation helpful? Give feedback.
-
Type:
BUNDLEIDIdentifier:
TEAM_ID:BUNDLE_ID(43AQ936H96:org.mozilla.firefoxdeveloperedition)Pros:
Beta Was this translation helpful? Give feedback.
All reactions