| 21 Jun 2021 |
 siraben | * and the more the environments under which you perform the build differ, if you still maintain identical binaries that's really good and the claim is even stronger | 08:04:57 |
 raboof | taviso also makes a lot of incorrect assumptions on how we would use reproducibility, which makes his posts even harder to follow | 08:05:18 |
| raboof | * taviso also makes a lot of incorrect assumptions on how we would use reproducibility, which makes the argument even harder to follow | 08:05:32 |
| siraben | "the developer can insert a malicious bug therefore reproducibility is moot" | 08:08:02 |
| raboof | atemu12: you mention you successfully reproduced the 21.05 ISO - did you also compare it to the one published at https://nixos.org/download.html ? When I did that I ran into https://github.com/NixOS/nixpkgs/issues/125380 | 08:09:25 |
|  Foxboron joined the room. | 08:14:42 |
| Foxboron | Tavis in a nutshell: https://xkcd.com/2368/ | 08:16:19 |
| Foxboron | But, not why I joined :) How is Nixos dealing with the linux signing key which gets generated during build to sign modules? | 08:16:52 |
| raboof | Foxboron: IIRC we disable module signing, and then no key is generated (https://github.com/NixOS/nixpkgs/pull/107625) | 08:18:28 |
| Foxboron | Thats.. uh.. not good? It makes lockdown mode unusable on NixOS if I'm not mistaken | 08:19:13 |
 Linux Hackerman | See the PR comments | 08:19:54 |
| Foxboron | Yeah, that's not a good solution. But it also explains why I couldn't figure out how it was dealt with. :/ | 08:21:12 |
| raboof | In reply to @foxboron:archlinux.org
Thats.. uh.. not good? It makes lockdown mode unusable on NixOS if I'm not mistaken it makes lockdown unusable on a plain NixOS installation, but if you want lockdown, you likely also want other customizations. That is still very much possible on NixOS | 08:22:23 |
| raboof | 'unusable' is perhaps not the right word, 'disabled by default'? | 08:22:36 |
| Foxboron | You are also loosing the ability to detect tainted modules on any normal nixos installation. That is a net negative in terms of security for any live deployment. | 08:23:22 |
| Foxboron | But yes, disabled by default is the correct word. | 08:23:40 |
| raboof | for example, when using distro-provided signed modules, even after lockdown someone could get the signed modules for a floppy disk driver and elevate their privileges. Better to custom-compile a kernel and only sign the modules you want to have available on your secure system, or even disable the module system entirely. (though I realize I'm somewhat making the XKCD 2368 argument now ;) ) | 08:25:45 |
| raboof | * for example, when using distro-provided signed modules, even after lockdown someone could get the signed modules for a floppy disk driver with a vulnerability and elevate their privileges. Better to custom-compile a kernel and only sign the modules you want to have available on your secure system, or even disable the module system entirely. (though I realize I'm somewhat making the XKCD 2368 argument now ;) ) | 08:26:01 |
| Foxboron | I was partially expecting some grandeur solution where a problem is completely negated because of some nixos feature :p | 08:27:14 |
| raboof | sorry :) | 08:27:28 |
| raboof | In reply to @foxboron:archlinux.org
You are also loosing the ability to detect tainted modules on any normal nixos installation. That is a net negative in terms of security for any live deployment. not sure about 'net negative' overall, but that's indeed a disadvantage. I wonder if we could have our cake and eat it, too, here: after all, to detect tainted modules you only need to somehow have a trusted set of checksums, you don't need a signature | 08:30:35 |
| Foxboron | In Arch we have been contemplating just splitting out key material to a separate package and declare it "non-reproducible". But it is non-obvious how to best approach the issue. Which is why I was curious what you where doing :) | 08:32:04 |
| Foxboron | In reply to @raboof:matrix.org
not sure about 'net negative' overall, but that's indeed a disadvantage. I wonder if we could have our cake and eat it, too, here: after all, to detect tainted modules you only need to somehow have a trusted set of checksums, you don't need a signature I'm not sure how this would work without kernel support though. Having the lockdown mode available is a great feature even if fairly unusable with DKMS without kernel patching currently. | 08:33:13 |
| Linux Hackerman | I think what would probably make sense is to have "local" signatures generated outside the scope of the kernel build (indeed, outside the scope of any nix build) | 08:33:42 |
| Linux Hackerman | That has the disadvantage of requiring a signing key that resides on the machine which is booting the kernel in question | 08:34:08 |
| Linux Hackerman | but the advantage of also being applicable to out-of-tree kernel modules (like zfs). We don't have dkms for that sort of thing because of how nix works | 08:34:48 |
| Linux Hackerman | I'm also not sure if it's feasible to patch a differnet key into the kernel image after the fact? But I imagine it should be. | 08:35:18 |
| raboof | in the NixOS context I'm not sure it's worth it since it's so easy to build bespoke kernels anyway... | 08:36:22 |
| Linux Hackerman | Secure boot is a similar topic, and (while it's not merged yet) this PR takes a similar approach to that https://github.com/NixOS/nixpkgs/pull/53901 | 08:36:53 |
| Foxboron | It's non-trivial. There are some null bytes in the linux initrd where you can just insert a public key and the kernel is going to accept it as a module signing key, but afaik it's missing in the efistub(?). Other distributions actually include a rejected out-of-tree patch where Secure Boot keys (OEM and MOK) are inserted into the keyring. | 08:36:41 |
