[wip] codesigning on Darwin #38624
[wip] codesigning on Darwin #38624
Conversation
|
Success on x86_64-linux (full log) Attempted: antlr, pbzx, xcbuild Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: pbzx, xcbuild The following builds were skipped because they don't evaluate on aarch64-linux: antlr Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: antlr, pbzx, xcbuild Partial log (click to expand)
|
GrahamcOfBorg
added
10.rebuild-darwin: 101-500
and removed
10.rebuild-darwin: 11-100
labels
|
Success on x86_64-linux (full log) Attempted: antlr, gdb, lldb, pbzx, xcbuild Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: antlr, gdb, lldb, pbzx, xcbuild Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: gdb, lldb, pbzx, xcbuild The following builds were skipped because they don't evaluate on aarch64-linux: antlr Partial log (click to expand)
|
|
Without code signing applications are not allowed to use the |
|
@Mic92 yes and SIP adds even more restrictions. |
|
I'm having trouble at dealing with macOS keychains in multi-user mode. Single-user mode would probably just work out of the box though. So we probably will need to import the private key into the builder (might be unsafe given NixOS/nix#8). Anyway this is kind of blocked on #38633. |
|
@GrahamcOfBorg build darwin.gdb |
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: darwin.gdb Partial log (click to expand)
|
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: darwin.gdb Partial log (click to expand)
|
|
Failure on x86_64-darwin (full log) Attempted: darwin.gdb Partial log (click to expand)
|
|
Hmm, I'll have to look carefully at this. I didn't think it was really possible to do codesigning in a principled/secure manner in Nix so I'll be happy to be proven wrong, but am also a bit apprehensive 😄 unless you see this purely as a "we give Hydra signing keys and you only get signatures if you get your binaries from the binary cache" deal. |
That's mostly what I want. Everything should be done in config options though so you could also self-sign everything. Basically we want to be able to do something like: And automatically have a signed GDB. I believe this is actually fairly similar to how binary cache signatures work. |
|
Success on x86_64-linux (full log) Attempted: gdb, lldb, xcbuild Partial log (click to expand)
|
|
So this is now basically blocked on #39308. |
|
I think the big problem with this is we can't really store secrets in the Nix store. The key will be publicly available to anyone who can access the .drv file. I don't think it would be a good idea to do this on Hydra until Nix can support some sort of private key impurity. |
This actually makes it useful to the Darwin stdenv, which I'll soon be adjusting to use this library
|
Hm... It's too bad there's not a way to tell macOS that a binary should be trusted without altering it. Currently, if we wanted to sign binaries from Nix, it would be impure and it would produce binaries that can't be |
|
Welp, I guess I should have read the manual before commenting, because it appears that exactly that is possible: |
|
Just tested. Seems to partially work: However, GDB still does not work... Still suggests that it's not codesigned. So for some reason, EDIT: Oh, also, just to show that the binary was unaltered: |
|
Pretty sure {LL,G}DB need not only a signature but an entitlement ( |
|
@copumpkin Ah. Also, I'm guessing all the dynamic libraries |
|
Yup |
|
Ah ha! Got it working. Had to sign all the dylibs it used, and I had to open the "Get Info" page for the certificate, open the "Trust" section, and set "Code Signing" to "Always Trust". Once I'd done that, I could use Does this seem like a viable path forward? Simply making zero changes in nixpkgs and instead finding some way to automate the detached signing of binaries? |
|
@ElvishJerricco I think the detached signatures will be helpful but still don't address most of what I wrote in my longer comment above, which I don't think is really easily addressable. We could have a special case to cover the common case and have Hydra sign a handful of binaries in some ad-hoc way, which would get most of us a working gdb/lldb/dtrace/git, but the local signing story is still pretty unclear to me, fundamentally. We can work around it but it would basically be negating the value of one security control Apple deliberately put in place, and I don't want to be known as "the package manager that makes your computer less secure" unless we give people a very loud option for opting into it. |
|
@copumpkin I don't think we need Hydra to provide macOS signatures in any way. I see two possible paths forward, both using local signing:
The issue is that it'll prompt the user for every binary we try to sign, but we can maybe work around that with with some kind of TTL / caching. |
|
Hydra could in theory also provide detached macOS signatures, if there's a way to add a pre-computed detached signature to this magic database. Maybe Nix should have a more pluggable concept of metadata, so that we can ship arbitrary kinds of signatures with a path, and just use Nix plugins to verify them properly? |
|
No, my point is that the notion of "local signing" is actively working against a security mechanism that Apple put in place, and I don't want that to be our default stance/policy unless you actively opt in. Basically, Apple added code signatures and entitlements to make it harder for local code to escalate privileges. If we then go add a local trusted codesigning certificate and private key accessible to the local box, then malicious local code could use that key as well as we could and circumvent the mechanism. That's what I meant by "I don't want Nix to be known as the package manager that disables macOS security mechanisms". I'm not 100% on board with the value of code signing here, but as a matter of policy I'd rather not go against the prevailing grain of the OS we're running on either. This is why I was suggesting that Hydra do it, and not enable local signing unless someone very explicitly allows it. |
|
Then it sounds like option 1 would be ok. Nix does not have to sign anything; users can just sign things themselves when they want. One way or another, their gdb has to be signed for it to work, and that signature isn't going to come from apple if gdb comes from nix. So sure, make it something they have to do themselves. But maybe automate it so they can do so easily. |
|
This doesn't on its own effect Apple's security. It just gives you a way of knowing the identity of who built your binary. It will all depend on what certificate you use to sign things. If its locally generated, then you will need to manually "trust" that certificate. Otherwise you can use a real one from the developer program. The main issue is that you can't really keep a file a secret in Nix. I would be interested if anyone has ideas for alternatives to this. Your private key should never be made publicly available through the Nix store. |
|
@matthewbauer I would suggest that you shouldn't sign binaries within a Nix expression. That should be left to external tooling, like |
Summary:
vscode-lldb has been broken on Darwin due to a build-time issue:
* on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
writable, NixOS#202507
and several runtime-issues:
* codelldb can't find its dynamic libraries (NixOS#160874)
* lldb-server from nixpkgs doesn't work due to missing the
"com.apple.security.cs.debugger"
macOS codesigning entitlement, (NixOS#38624), also with the symptom that
tccd, the macOS "Transparency, Consent, and Control" daemon, denies
requests it receives from vscode/codium with log messages like:
"AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
"Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
"AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.
* lldb-server from nixpkgs may also provide a different CLI interface than
codelldb expects on macOS.
* vscode-lldb directs lldb to load rust pretty-printing scripts which need
to be preserved through the build process in nixpkgs
Solution:
* The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
in NixOS#202507.
* The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
wrapping codelldb
* The permissions issue and CLI interface issue can both be fixed by using
Xcode's debugserver,
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
on macOS, since it has the required entitlement and the expected interface.
* Finally, the script-loading issue can be fixed by copying the required
scripts to the location that vscode-lldb expects to find them in.
Fixes:
* NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
with vscode-extensions.vadimcn.vscode-lldb
* NixOS#160874: codelldb inside of vscode-lldb extension doesn't work
* NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin
(cherry picked from commit fa70e74)
Summary:
vscode-lldb has been broken on Darwin due to a build-time issue:
* on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
writable, NixOS#202507
and several runtime-issues:
* codelldb can't find its dynamic libraries (NixOS#160874)
* lldb-server from nixpkgs doesn't work due to missing the
"com.apple.security.cs.debugger"
macOS codesigning entitlement, (NixOS#38624), also with the symptom that
tccd, the macOS "Transparency, Consent, and Control" daemon, denies
requests it receives from vscode/codium with log messages like:
"AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
"Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
"AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.
* lldb-server from nixpkgs may also provide a different CLI interface than
codelldb expects on macOS.
* vscode-lldb directs lldb to load rust pretty-printing scripts which need
to be preserved through the build process in nixpkgs
Solution:
* The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
in NixOS#202507.
* The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
wrapping codelldb
* The permissions issue and CLI interface issue can both be fixed by using
Xcode's debugserver,
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
on macOS, since it has the required entitlement and the expected interface.
* Finally, the script-loading issue can be fixed by copying the required
scripts to the location that vscode-lldb expects to find them in.
Fixes:
* NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
with vscode-extensions.vadimcn.vscode-lldb
* NixOS#160874: codelldb inside of vscode-lldb extension doesn't work
* NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin
This is the start on my quest to get codesign working on macOS. In the end this should close #37838, #18420, #17406 and maybe #15889 and #36223 (lots of other gatekeeper issues especially with jamf and other AVs).
The main thing is packaging "security_systemkeychain" which contains the source for codesign. There is some difficulty here in how Apple has left out a few important packages. We can kind of hack through it with @samdmarshall's OSXPrivateSDK. Probably can't/shouldn't redistribute "codesign" but hopefully still usable in "nativeBuildInputs".
Eventually, I want Hydra to start signing binaries for certain executables. Some that are definitely needed: (it might be useful for others too)
For this to work we will need to run codesign on certain binaries probably in a setup-hook. This is the man for codesign:
We will need an "identity" provided as a config option to Nixpkgs (default to "$CODE_SIGN_IDENTITY"). I'm not sure how we would get the identities on the Hydra machines but I think it would be useful for lots of users (although this would obviously break reproducibility).
To use this right now follow the steps 1-9 here https://gist.github.com/hlissner/898b7dfc0a3b63824a70e15cd0180154 giving the certificate the name "nixpkgs". Now you can use
darwin.gdbanddarwin.lldb.Usage
You can start using this right now. Configuration is a little tricky so I will take a step by step approach.