It's one thing to notify the user (or outright block a process launch) when a code signature is broken, but it would also be nice to notify the user, when the signature has changed (between launches, after updates, after developer account change, after re-signing etc.).
Reason: malware could (at least in theory) change an app, and before launching it, re-codesign the bundle, either ad-hoc or using a certificate that's bundled with the malware (incl. the private key). Then an infected app would have a signature that's "valid on disk" and "satifsfies its designated requirements", and would probably launch, especially if the malware also removes the quarantine XA.
Problem: you can't really use the SHA-256 hash of a certificate, because afaik those change every time a developer renews his Apple developer account (updated certificate).
However, what does not change to my knowledge, is the Subject Key Identifier (SKID). So as long as the developer account behind an app doesn't change, the SKID will remain the same.
Caveat: third-party signatures not issued by Apple (like those used by the Skim PDF reader) don't have SKID to begin with, and in those cases the SHA-256 should be used.
A functionality like this would need a protected local database, where Sinter stores the SKID, the SHA-256, and the notarized yes/no status, the commonName, the Team ID, the Bundle ID, the path to the app or executable… and other necessary info.
A warning prompt for the user would appear (for example) if:
a previously notarized app or executable (CLI tool etc.) is suddenly not notarized anymore
a process previously signed with an Apple cert is now signed with a third-party cert or ad-hoc
the Team ID has changed
the commonName of a signing certificate has changed
the SKID of the certificate behind a code signature has changed
a process with an associated SKID in the signing certificate is suddenly signed with a certificate that doesn't contain a SKID anymore
a signature originally performed with a certificate without a SKID now has a new signature with a certificate that has a different SHA-256 checksum
Checks like these would probably slow down process launches, especially if the information needed for such a functionality isn't available from the Kernel/EndpointSecurity API. In the former case, it should be an opt-in functionality, and in the latter case, it wouldn't be possible anyway, unless Sinter offers the option to lauch a (shell) script, which can then be implemented with an individual solution by user, i.e. (1) Sinter halts process launch (SIGSTOP), (2) passes all relevant data (incl. PID) to user-defined shell script, (3) shell script performs additional checks, (4a) all OK > kill -s -CONT $pid, or (4b) problems > script will prompt user, and then kill -s KILL $pid or kill -s -CONT $pid (depending on user choice).
It's one thing to notify the user (or outright block a process launch) when a code signature is broken, but it would also be nice to notify the user, when the signature has changed (between launches, after updates, after developer account change, after re-signing etc.).
Reason: malware could (at least in theory) change an app, and before launching it, re-codesign the bundle, either ad-hoc or using a certificate that's bundled with the malware (incl. the private key). Then an infected app would have a signature that's "valid on disk" and "satifsfies its designated requirements", and would probably launch, especially if the malware also removes the quarantine XA.
Problem: you can't really use the SHA-256 hash of a certificate, because afaik those change every time a developer renews his Apple developer account (updated certificate).
However, what does not change to my knowledge, is the Subject Key Identifier (SKID). So as long as the developer account behind an app doesn't change, the SKID will remain the same.
Caveat: third-party signatures not issued by Apple (like those used by the Skim PDF reader) don't have SKID to begin with, and in those cases the SHA-256 should be used.
A functionality like this would need a protected local database, where Sinter stores the SKID, the SHA-256, and the notarized yes/no status, the commonName, the Team ID, the Bundle ID, the path to the app or executable… and other necessary info.
A warning prompt for the user would appear (for example) if:
Checks like these would probably slow down process launches, especially if the information needed for such a functionality isn't available from the Kernel/EndpointSecurity API. In the former case, it should be an opt-in functionality, and in the latter case, it wouldn't be possible anyway, unless Sinter offers the option to lauch a (shell) script, which can then be implemented with an individual solution by user, i.e. (1) Sinter halts process launch (
SIGSTOP), (2) passes all relevant data (incl. PID) to user-defined shell script, (3) shell script performs additional checks, (4a) all OK >kill -s -CONT $pid, or (4b) problems > script will prompt user, and thenkill -s KILL $pidorkill -s -CONT $pid(depending on user choice).