Codesigning everything and combatting malicious code

[Ryan Schmidt]

On Mar 21, 2022, at 23:02, Joshua Root wrote:

> We could ad-hoc codesign everything, which would not improve security at all, but would get GateKeeper to ease up a bit on restrictions on incoming network connections and the like.

> Assurance that binaries have not changed after being installed would be nice I suppose.

Ok, those could be useful qualities. A binary could change because of malicious actions or just because the disk it's stored on is failing. Preventing the binary from being used in either of those cases is probably good.

If we did ad-hoc codesiging in MacPorts then we would not need to use any Developer ID and we would have the same safeguards for Intel and PowerPC systems that we already have automatically on Apple Silicon systems. Would that be of any benefit?

"man codesign" says "Significant restrictions apply to the use of ad-hoc signed code; consult documentation before using this." I don't know which documentation it means. I found this page discussing the restrictions:

https://apple.stackexchange.com/questions/288291/what-are-the-restrictions-of-ad-hoc-code-signing

Most of the answer provided there is incomprehensible to me except for the conclusion that an ad-hoc signed binary is "basically [...] the same as a non-signed binary". Are we sure that ad-hoc codesigning is enough to pacify GateKeeper? Since all binaries must be codesigned on Apple Silicon, does that mean that GateKeeper never has anything to complain about on Apple Silicon systems?

The code signature appears to be stored within the file being codesigned. (I ad-hoc codesigned an unsigned binary produced by MacPorts and its size increased by 25K.) What happens if file is completely replaced? I assume the previous file's code signature does nothing to prevent that. We have at times had the situation where a user runs a third-party installer that installs older files on top of the files MacPorts installed, causing various problems. But I'm guessing codesigning wouldn't do anything to prevent that situation, in which case codesigning doesn't really prevent modification of the file in the way that one might expect.


> Codesigning is a in the end just a mechanism, and there are policy questions that need to be thought through before it can be useful.

Yup, and thanks for raising some of those questions in your response!