Re: Codesigning everything and combatting malicious code
> On 24 Mar 2022, at 19:24, Joshua Root wrote: > > On 2022-3-23 08:19 , Ryan Schmidt wrote: >> On Mar 21, 2022, at 23:02, Joshua Root wrote: >> 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? > > No. As I said before, an ad-hoc signature does nothing to improve security, > and the designers of GateKeeper are aware of that. Having a signature from > someone you've never heard of doesn't help in deciding whether to trust the > signed item. > > I think what it does do is prevent repeated authorisation prompts for the > same program, as long as GateKeeper can see that its signature has not > changed since last time the user said to trust it, and is still valid. > > - Josh It's been a while, but this summer, after I moved from Mojave to Monterey, I started to experience serious problems with my macOS server (based on MacPorts of postfix, dovecot, etc.). Without clear proof, but on intuition, I have deiced that the most likely reason is that Apple doesn't handle exceptions to signing very well (problems with alf, launchd, pf, but most seriously, the system doesn't handle many service requests (ports sockets) very well and gets stuck tregularly for 30minutes to an hour. When it is stuck, it reacts to ping, but no other connection can be opened. Then when it gets unstuck, apparently there has been some sort of garbage collection going on and there is again room. From 12.5.1 to 12.6.2 this has gotten worse: the system will not react to ping even, will not get unstuck by itself, it requires a hard reset (power). This is unacceptable for a server where I am not always around to do that (let alone the potential data corruption that follows). For me, not having a system where I can reliably run my services as I have been doing during the NeXT days and then the Mac OS X Server days and then the macOS + MacPorts days is unacceptable. A system that is able to hang itself in such a way is not a serious production environment. Forget security, macOS might become utterly unreliable because Apple writes buggy code that doesn't handle two different security models side by side very well. So, I have been moving my stuff to Linux and I'm almost done. I will keep macOS + MacPorts as a second system so I will go to failover mode for some services. G
Re: Codesigning everything and combatting malicious code
> (nb: This is firefox ESR 52.9. Yes, I know it's old. There's no reasonable
> newer version for this old OS, and upgrading the OS breaks too many things.)
Sorry for being off-topic, but—yes there is!
On the Firefox side there's 78 ESR. It's a bit outdated now, but a lot better
than ESR 52.9. https://www.mozilla.org/en-US/firefox/78.0esr/releasenotes/
And then if you don't mind jumping ship, there's Chromium Legacy:
https://github.com/blueboxd/chromium-legacy (I recommend installing via a
PrefPane I created, so you'll receive automatic updates:
https://github.com/blueboxd/chromium-legacy/discussions/25). This browser is
fully up-to-date with mainline Chrome.
On Mar 24, 2022, at 4:48 PM, Michael wrote:
> I am still on a 10.9.5 system, and I am consistently seeing messages from
> sandbox in the system log that a certain program, that uses a helper program,
> cannot receive some messages because of a signing problem.
>
> Would this be helped by using adhoc local signing when installing?
>
> (nb: This is firefox ESR 52.9. Yes, I know it's old. There's no reasonable
> newer version for this old OS, and upgrading the OS breaks too many things.)
>
> Mar 23 13:47:59 keybounceMBP appleeventsd[140]: A
> sandboxed application with pid 33358, "Firefox Web Content" checked in with
> appleeventsd, but its code signature could not be validated ( either because
> it was corrupt, or could not be read by appleeventsd ) and so it cannot
> receive AppleEvents targeted by name, bundle id, or signature. Error=ERROR:
> #-67061 { "NSDescription"="SecCodeCheckValidity() returned -67061, 0x7f9963b28ae0 [0x10713af00]>." } (handleMessage()/appleEventsD.cp #2072)
> client-reqs-q
>
> Mar 23 13:47:59 keybounceMBP plugin-container[33358]: Failed to allocate
> communication port for com.apple.CFPasteboardClient; this is likely due to
> sandbox restrictions
>
>
Re: Codesigning everything and combatting malicious code
I am still on a 10.9.5 system, and I am consistently seeing messages from
sandbox in the system log that a certain program, that uses a helper program,
cannot receive some messages because of a signing problem.
Would this be helped by using adhoc local signing when installing?
(nb: This is firefox ESR 52.9. Yes, I know it's old. There's no reasonable
newer version for this old OS, and upgrading the OS breaks too many things.)
Mar 23 13:47:59 keybounceMBP appleeventsd[140]: A
sandboxed application with pid 33358, "Firefox Web Content" checked in with
appleeventsd, but its code signature could not be validated ( either because it
was corrupt, or could not be read by appleeventsd ) and so it cannot receive
AppleEvents targeted by name, bundle id, or signature. Error=ERROR: #-67061 {
"NSDescription"="SecCodeCheckValidity() returned -67061, ." } (handleMessage()/appleEventsD.cp #2072)
client-reqs-q
Mar 23 13:47:59 keybounceMBP plugin-container[33358]: Failed to allocate
communication port for com.apple.CFPasteboardClient; this is likely due to
sandbox restrictions
Re: Codesigning everything and combatting malicious code
On 2022-3-23 08:19 , Ryan Schmidt wrote: On Mar 21, 2022, at 23:02, Joshua Root wrote: 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? No. As I said before, an ad-hoc signature does nothing to improve security, and the designers of GateKeeper are aware of that. Having a signature from someone you've never heard of doesn't help in deciding whether to trust the signed item. I think what it does do is prevent repeated authorisation prompts for the same program, as long as GateKeeper can see that its signature has not changed since last time the user said to trust it, and is still valid. - Josh
Re: Codesigning everything and combatting malicious code
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!
Re: Codesigning everything and combatting malicious code
Apologies if what I'm about to say seems tangential... hopefully it provides historical context that is useful to the discussion at hand. = Remember that code signing was first implemented for apps that were published on the iOS App Store. This was very quickly (maybe even simultaneously?) adopted for the Mac App Store. Since the code signing was generally seen as "a good thing"™ in terms of security, Apple has since rolled it out nearly everywhere. Some people, including me, have seen this as just one more indication of the "iOS-ification" of the Mac operating system, a process which began when they renamed Mac OS X to macOS. Another example of the "iOS-ification" of macOS is where, starting in Catalina, and then in Big Sur, Apple moved the System volume to a partition that is mounted read-only, and then also sealed that volume into a Signed System Volume (SSV). (See? there's that word again... "Signed".) This structure of a read-only and signed volume that contains the entire operating system is the way that iOS has been structured for a very long time (maybe even since the beginning). Getting around this structure, and turning the volume where iOS resides into one that is read-write, is one part of what is generally referred to as "jailbreaking" iOS. Apple's app stores are highly centralized, being 100% hosted, administered, and controlled by a single entity. Thus, they have a need for code signing, so that they can use the code-signing keys as a mechanism to control whether or not a third-party developer's app is allowed to be visible to the public through their (first party) app stores. On the other hand, MacPorts is much more similarly structured *—* in terms of infrastructure, governance, and philosophy *—* to a package manager on Linux, and is highly decentralized. This sentiment appears to be echoed in Wikipedia's article on code signing (https://en.wikipedia.org/wiki/Code_signing), in the last paragraph of the section entitled "Providing security". In particular, I would like to point out the citation at the end of that paragraph, which links to a discussion of apt-secure on the Debian wiki ( https://wiki.debian.org/SecureApt). If you read through the Debian wiki page, you will see that, circa 2003-2005, when Debian moved away from simply using MD5 checksums, they decided to go the route of using public key cryptography in the form of GPG keys, instead of going down the road of code signing the way that Apple has implemented it. = On Tue, Mar 22, 2022 at 12:02 AM Joshua Root wrote: > On 2022-3-22 12:20 , Ryan Schmidt wrote: > >> Could MacPorts codesign everything installed by ports? If so, should we? >> What benefits would that bring? How would we do it? > > > 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. If ad-hoc code-signing everything would not involve the need for anyone, either on the MacPorts side or the user side, to have a Developer ID, then it seems like this would generally be a good idea. Reducing the number of interactions with GateKeeper would help reduce user confusion. (Does anyone remember the frequency of the UAC prompts in Windows Vista?) Doing actual useful codesigning would require a few things: > 1. A Developer ID for the project. I'm happy to sign the installers with my > personal Developer ID because I build them myself and I am familiar with > the code contained in them. I would not sign arbitrary third party code. > 2. A Developer ID for every user who needs to install any ports that are not > available as binaries. We obviously can't distribute our secret key to > the public, so anything built locally needs to be signed locally, with a > locally configured identity. > This seems like it would be adding a huge burden onto people who simply want to use MacPorts. > 3. A willingness to endorse every binary we ship by putting our signature > on it. > Does MacPorts, as a group of developers, really want to be in the business of endorsing every binary that's available in our catalog of nearly 30,000 packages? The various Linux package management systems certainly don't make any such claims or guarantees, and in fact explicitly state the opposite. And even though Apple also has text stating that they don't "endorse" any apps in their app stores, the fact of the matter is that they do still take it upon themselves to police the apps (and the developers) on their app stores. This also relates back to point #1, where the MacPorts Developer ID would be getting used to arbitrarily sign third-party code. 4. A plan for what to do if we inadvertently ship malware and our Developer > ID certificate is revoked. AIUI, that would make it impossible to run > anything signed with the existing certificate if GateKeeper is enabled. > Everything would presumably have to be re-signed and reinstalled. > I believe Josh is correct. A
revision control downloads (was Re: Codesigning everything and combatting malicious code)
On Mar 21, 2022, at 9:20 PM, Ryan Schmidt wrote: > Ports that fetch their sources from a revision control system do not enjoy > the protection of checksums. Although ports that fetch source from a revision > control system specify which tag or commit hash to fetch, it is conceivable > that a developer with sufficient access to that repository could delete an > old tag and replace it with a new tag of the same name that contains > different software. This is one of the reasons why we recommend ports fetch > using distfiles, and the vast majority do. We might consider recommending > that ports that fetch directly from a git repository (fetch.type git) never > use a tag, and always use the commit hash corresponding to that tag, since > replacing the contents of the repository while keeping the same sha1 hash is, > as far as I know, still impossible in the general case. (Yes, it is possible > to engineer a sha1 collision, but only if you can carefully control both the > old and new files. Generating a sha1 collision against some existing old file > is a very different matter.) I haven't reviewed the current literature but one thing is certain - attacks only get better. We should strongly discourage any use of revision control as the source. We could shorten the window where a person could get sources that don't match what the maintainer expected with a little infrastructure magic. Roughly in order of presumed level of effort: - provide a place for maintainers to manually upload distfiles that they can generate from a source checkout - provide some port command for maintainers to upload distfiles (as a convenience for the above upload process) - have a process that automatically generates distfiles from the checked out source and puts it on our mirrors (builder could probably do this since it's already going to check out the source), then have base look for the distfile on our mirrors first (even if the portfile specifies to check out from a revision control system) -- Daniel J. Luke
Re: Codesigning everything and combatting malicious code
On 2022-3-22 12:20 , Ryan Schmidt wrote: It is not even our policy that contributors must read the NEWS or CHANGELOG files to see what changed, though I sometimes do this as it helps me discover things like if dependencies need to be changed. It may not be required by policy, but I would consider reading the release notes to be basic due diligence before updating a port. There are many kinds of incompatible changes that might otherwise easily be missed. Could MacPorts codesign everything installed by ports? If so, should we? What benefits would that bring? How would we do it? 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. Doing actual useful codesigning would require a few things: 1. A Developer ID for the project. I'm happy to sign the installers with my personal Developer ID because I build them myself and I am familiar with the code contained in them. I would not sign arbitrary third party code. 2. A Developer ID for every user who needs to install any ports that are not available as binaries. We obviously can't distribute our secret key to the public, so anything built locally needs to be signed locally, with a locally configured identity. 3. A willingness to endorse every binary we ship by putting our signature on it. 4. A plan for what to do if we inadvertently ship malware and our Developer ID certificate is revoked. AIUI, that would make it impossible to run anything signed with the existing certificate if GateKeeper is enabled. Everything would presumably have to be re-signed and reinstalled. As you can see, the challenges are significant, and the benefits of just slapping a Developer ID signature on what we already produce are largely questionable. Assurance that binaries have not changed after being installed would be nice I suppose. 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. - Josh
Codesigning everything and combatting malicious code
Sorry, this got long. I want to move a discussion to the macports-dev list that began with a user's question to macports-mgr. This user ran a third-party utility which reported that some files installed by MacPorts were not codesigned and asked if it was a concern. I replied that the files installed by the MacPorts installer are codesigned but that MacPorts predates the existence of codesigning and nobody has yet added code to MacPorts that arranges for files installed by ports to be codesigned. Individual ports might codesign their files if that's how their build system was written. On Apple Silicon all (code?) files must be codesigned and the linker (?) takes care of ad-hoc codesigning the files automatically. I also said I wasn't really clear on what purpose codesigning serves; MacPorts and macOS got by fine without it for years. The user replied asking if codesigning might reduce the risk of compromised open source packages, referencing this incident in which the developer of node-ipc deliberately released a version containing malicious code: https://www.schneier.com/blog/archives/2022/03/developer-sabotages-open-source-software-package.html This is a hypothetical question since node-ipc is not in MacPorts and as far as I know a similar situation has not happened with any software that we do have in MacPorts. And since then node-ipc appears to have been forked by a different developer and a new non-malicious version has been released. I felt that the broader MacPorts developer community might care to hear a reply to this or to discuss whether and how we should modify MacPorts base to codesign everything installed by ports. ~ Certainly the situation with node-ipc was undesirable but I don't see how MacPorts codesigning its files would solve it. I'll talk about that in a minute. First let me discuss what safeguards MacPorts already contains. MacPorts ports already fetch specific maintainer-tested versions of the source code. If a developer releases a new version, nothing changes in MacPorts until a MacPorts contributor updates the Portfile to use that new version. Before doing so the MacPorts contributor is expected to verify that the port at least compiles on one macOS version; that the port's test phase runs, if the port has one; that "port lint" doesn't show any easily fixable mistakes; and ideally that some basic functionality of the installed files works. If the port has subports, this applies to all subports as well. MacPorts already checksums distfiles. The MacPorts master build server saves a copy of distfiles (assuming the checksum matches at the time) and these are mirrored on servers around the world. If a developer replaces a distfile on their server with something else (maliciously or not), MacPorts will not install the port using that distfile; it will issue a checksum mismatch error and tell the user how to report it to us. Or MacPorts might download the previous "good" file from a MacPorts mirror, bypassing the developer's new replacement file. When we notice such a "stealth update" has occurred, proper procedure is to compare the old and new file to see whether something malicious has happened so that we can decide whether we should modify the port to use the new file or to bypass it. (We might also bypass a new developer distfile if it contains no relevant differences from the old one.) Ports that fetch their sources from a revision control system do not enjoy the protection of checksums. Although ports that fetch source from a revision control system specify which tag or commit hash to fetch, it is conceivable that a developer with sufficient access to that repository could delete an old tag and replace it with a new tag of the same name that contains different software. This is one of the reasons why we recommend ports fetch using distfiles, and the vast majority do. We might consider recommending that ports that fetch directly from a git repository (fetch.type git) never use a tag, and always use the commit hash corresponding to that tag, since replacing the contents of the repository while keeping the same sha1 hash is, as far as I know, still impossible in the general case. (Yes, it is possible to engineer a sha1 collision, but only if you can carefully control both the old and new files. Generating a sha1 collision against some existing old file is a very different matter.) Some ports' build systems fetch additional files from the Internet at build time. This too is discouraged in MacPorts. Who knows whether such build systems download specific versions of those files or whether their integrity is verified in any way. This represents another avenue by which unverified files (which might have been replaced with malicious versions) could make their way into a build of a port. And if that one server that the build system is programmed to download from is down, the installation fails. Ports should specify all their
