-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
linuxPackages{,_latest,_next}_hardened_ia32Emulation: init #81943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
These are variants of the hardened kernels that leave 32-bit x86 emulation enabled. Though it increases the attack surface, they're relatively well-trodden code paths, and since I know people currently sometimes opt for the vanilla kernel in lieu of a hardened one that lets them continue using Wine, Steam, etc., in practice it'll offer people a net benefit to security. Resolves NixOS#79798.
cc @luis-hebendanz @yegortimoshenko who ❤'d the issue :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Binary emulation does increase attack surface, so another kernel build seems to make sense. Note the new hadenedLinuxPackagesFor
function signature.
@GrahamcOfBorg build linux_latest_hardened_ia32Emulation |
Should these packages be blacklisted on aarch64? It looks like it might be cross-compiling or something? |
I am against adding even more kernel package variants since it increases the amount of kernels I need to test when changing kernel options or adding new kernel modules. cc @NeQuissimus @joachifm I would very much prefer if you can decide what options to enable in the hardened profile or hide this option from being build on nixpkgs-review/hydra. |
When the hardened kernel and profile were first added, the idea was to enable as many mitigations as possible, even to the detriment of features and performance. Now, I'll grant that there's plenty of room for reasonable disagreement about what an acceptable loss of performance/features is versus hardening, but I for one consider breaking proprietary applications and drivers acceptable. If we could control this feature at boot or runtime, it'd be a no-brainer to make it available and leave it for the admin to decide. Deferring to the admin is my preferred approach for a distro kernel, but in cases where you have to make a yes/no decision at compile time, I think the hardened config must err on the side of hardening. In any case, I agree with @Mic92 that adding 3 additional package sets to accommodate a single option is probably too much. I think the community has to decide what hardened is supposed to mean and instead adjust the main hardened config accordingly. |
Unfortunately, it seems to be compile time only :(
Counterargument: not having it enabled was also a source of a few issue reports before #79798, namely #30702, #51097 (comment), #58240, #67577. A few other distributions that do ship an optional hardened kernel package also have IA32 emulation enabled: |
I propose opening a new PR that updates the hardened-config and leave it open for a bit to let interested parties vote on it. I still think its inappropriate despite what arch and alpine do but if users want it then that's fine I guess. |
Per discussion in NixOS#81943. Resolves NixOS#79798.
Closing in favour of #82006. |
Per discussion in NixOS#81943. Resolves NixOS#79798. (cherry picked from commit b628400)
Motivation for this change
These are variants of the hardened kernels that leave 32-bit x86
emulation enabled. Though it increases the attack surface, they're
relatively well-trodden code paths, and since I know people currently
sometimes opt for the vanilla kernel in lieu of a hardened one that lets
them continue using Wine, Steam, etc., in practice it'll offer people a
net benefit to security.
Resolves #79798.
@GrahamcOfBorg build linuxPackages_latest_hardened_ia32Emulation
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)