You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Santa displays the "Signing ID" field in santactl fileinfo output as a combination of "TeamID:SigningID". For platform binaries which don't have a TeamID, we use the hardcoded string "platform". Because Santa intentionally does not allow SID rules for adhoc signed binaries, Santa will only treat an SID as valid if the TID is set, or it is a platform binary.
whether or not something is a platform binary is really a runtime decision (I believe made by AMFI), however Santa treats it as a static decision.
For santactl fileinfo, the binary is obviously not necessarily running, only the path is evaluated. The current check for whether or not something is a platform binary is seeing if the kSecCodeInfoPlatformIdentifier key is set in the signing info dictionary for the file. This mostly works, except apparently when it doesn't... it seems to largely affect things that ship in protected paths (e.g. /Library/Apple), but are not part of the read only volume.
The slightly bigger issue is that because Santa does not treat things like this as a platform binary, it will not respect SID-based rules for these binaries. It's expected to be rare for folks to be settings rules for these types of things in the first place... but we'll still fix it. The fix for this part of the issue is straight forward since the evaluation is done at runtime and there is no need to rely on static checks.
Fixing the santactl fileinfo (and related santactl rule) issue is a bit more difficult. Will need to investigate if there are better static checks we can do to determine whether or not something is a platform binary.
The text was updated successfully, but these errors were encountered:
Santa displays the
"Signing ID"
field in santactl fileinfo output as a combination of"TeamID:SigningID"
. For platform binaries which don't have a TeamID, we use the hardcoded string "platform". Because Santa intentionally does not allow SID rules for adhoc signed binaries, Santa will only treat an SID as valid if the TID is set, or it is a platform binary.whether or not something is a platform binary is really a runtime decision (I believe made by AMFI), however Santa treats it as a static decision.
For santactl fileinfo, the binary is obviously not necessarily running, only the path is evaluated. The current check for whether or not something is a platform binary is seeing if the
kSecCodeInfoPlatformIdentifier
key is set in the signing info dictionary for the file. This mostly works, except apparently when it doesn't... it seems to largely affect things that ship in protected paths (e.g. /Library/Apple), but are not part of the read only volume.The slightly bigger issue is that because Santa does not treat things like this as a platform binary, it will not respect SID-based rules for these binaries. It's expected to be rare for folks to be settings rules for these types of things in the first place... but we'll still fix it. The fix for this part of the issue is straight forward since the evaluation is done at runtime and there is no need to rely on static checks.
Fixing the santactl fileinfo (and related santactl rule) issue is a bit more difficult. Will need to investigate if there are better static checks we can do to determine whether or not something is a platform binary.
The text was updated successfully, but these errors were encountered: