Enhancement idea: Wildcards in SigningID rules #1163
Comments
|
I have mixed feelings about this... On the surface I think this is a reasonable request, but the implementation has some downsides. Wildcard rules would definitely help from a standpoint of reducing overall policy size and likely improving readability of a policy. But I don't think they effectively reduce the amount of work required by a policy writer. My assumption is that a policy writer would need to first enumerate the binaries contained in a bundle and collect the signing IDs and verify that they do indeed want to create policy for each of those binaries. Once the SIDs are collected, they would then need to find some common prefix(es) that suited their needs. Since bundles can obviously change over time, with binaries added/removed, wildcards remain flexible to potentially reduce toil maintaining policy, but with tradeoffs. I think there are two potential goals of wildcards:
Perhaps some limited wildcard support would effectively add a "BundleID rule" capability without having to rely on bundle identification? However the policy would still be susceptible to bundle changes that add binaries with non-matching wildcards and policy writers would still be required to perform this maintenance. @p-harrison, I had a couple followup questions:
|
|
Thanks for the quick response Matt. All your points are well made! In answer to your follow-up questions -
|
|
Appreciate the responses! I believe that:
We're going to noodle on this a bit and will discuss more broadly when some folks get back from vacations. |
|
One point that may not be clear from my examples above - it would be great if the 'prefix' did not necessarily have to end at a full stop within a SigningID. I imagine you're just doing a string compare so perhaps this does not need to be stated... JAMF is a good example - |
|
Hey guys, I was just adding some SigningID rules for Firefox and it reminded me of this discussion. Wonder if you guys had any more thoughts on the viability of it? |
|
I don't think I've been very sold on the idea yet. Given an admin would still need to enumerate binaries within a bundle and determine some common prefix manually, I don't think there is much of a time savings. I'd also have some concerns around rules applying automatically to new binaries in future versions of the bundle, but I suppose that's a risk an admin could take.... I think the largest problems are technical - I see a few issues that would need to be solved. First, the current setup for doing a rule match requires a single query. For prefix matching, we'd have to figure out a good approach to do partial matching based on some given signing ID and presumably some number of various prefixes that could exist in the DB. We could maybe scope things to a given TeamID to help limit the number of potential matches, but we'd still need to iterate prefix results and match against the SID being authorized. We'd also have to decide how to handle multiple matches (e.g., longest rule match wins? Only allow one prefix rule per TID?). Second, given the above, we'd either need multiple queries, or we'd have to change the query to return potentially more than one row. Either way, we'd then need to perform precedence ordering in code. Right now we solely rely on our query to enforce our precedence. But with multiple rows/queries, we'd have to replicate this logic, which would require a whole slew of new tests. Third, I think we'd need some way to append extra metadata to a rule to indicate that the identifier is a prefix type. Just using All of these are fairly non-trivial and would require a bit of design to make sure edge cases are accounted for. Given the amount of effort to get something like this done, as well as the payoff not seemingly all that much (maybe a bit fewer rules per bundle), this is likely not going to be prioritized any time soon. |
|
Another idea to get something similar to bundle ID rules is that you could use a combination of bundle hash and signing ID in the Events to figure out what rules to generate. We do include the Signing IDs up to the server when a block event occurs, these events also have the bundle hash, which is derived from the binaries in the bundle. In theory you could use this with your sync server to identify all of the related signing IDs in a bundle and then send the corresponding singing ID allow rules to run the bundle. This is obviously more practical if you can get push notifications, which is still hard outside of Google's deployment. sequenceDiagram
santa ->> "sync service": Upload Blocked event
santa ->> "sync service": Upload Bundle Events with Signing IDs
"sync service" ->> "sync service": Generate signing ID allow rules for bundle
"sync service" -->> santa: Allow rules for bundle
Alternatively to get the list of Signing IDs in a bundle a priori you can use find, xargs and santactl e.g. $ find /Applications/Santa.app -type f -perm +111 | xargs santactl fileinfo --key "Signing ID"
com.google.santa.metricservice
com.google.santa.syncservice
com.google.santa
com.google.santa.bundleservice
com.google.santa.ctl
com.google.santa.daemon |
I wonder would it be feasible to support wildcards in SigningID rules? The usecase would be where you want to allow only specific applications from a developer, so a TeamID rule would be too broad, but the application contains multiple binaries. A Certificate rule might work, but again could be used by the developer across multiple applications, or conversely there might be multiple certificates used in a single application.
For example these rules would permit multiple binaries with a single rule, leading to a tidier more manageable rules database -
The text was updated successfully, but these errors were encountered: