Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
All these options are already the global defaults for Nixpkgs, as stated in the manual:
https://nixos.org/manual/nixpkgs/stable/#sec-hardening-in-nixpkgs
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.
I don't think that the documentation accurately reflects reality, given for example the existence of this pull request: #252310
I believe that openssh should explicitly opt-in to as many hardening options as possible, and not rely on sketchy documentation guarantees.
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.
hardeningEnable
. Or do you truly believefortify
will fortify the code because the sketchy documentation guarantees it, at the same time you don't believe the sketchy documentation guaranteesfortify
is already among the default hardening flags?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.
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.
You are implying the documentation does not reflect the code, however you are updating the code based on the same unreliable documentation.
I would agree in principle, however (again) the documentation does not reflect the code. So we should read the underlying code to verify if the flags will be effectively enabled.
Nice. I will watch this.
Well, if you push (say)
fortify
to ensure the most security-critical package explicitly opts-into more hardening, however the underlying Nixpkgs code does not fortify openssh, then we are effectively wasting time - and worse, providing a placebo.So we need at least some guarantee that openssh is effectively hardened.
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.
https://nixos.org/manual/nixpkgs/stable/#sec-hardening-flags-disabled-by-default
PIE
is already documented as disabled by default.The rest of the hardening flags are enabled either because of
nixpkgs/pkgs/build-support/cc-wrapper/setup-hook.sh
Lines 113 to 115 in 68b1fd2
hardeningEnable
are added toNIX_HARDENING_ENABLE = enabledHardeningOptions
in stdenv.hardeningEnable
is additive.#206490 is for making the option duplication unnecessary (if there are no drawbacks).
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.
I don't think I'd call the default hardening flags a "documentation guarantee". The documentation is just a supplement, the code is the real guarantee
nixpkgs/pkgs/stdenv/generic/make-derivation.nix
Lines 198 to 204 in aa73e0d
#206490 seems to regard the mechanisms between
mkDerivation
and more specific builder functions, not the hardening defaults themselves. I don't think it's something to worry about, it's just setting a more sane default to reduce some unnecessary boiler plate for the other builder functions.Running
checksec
on the openssh binaries reports all of the flags as enabled (don't know about the other errors, but they seem irrelevant)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.
after applying this PR
stack clash protection should be a false positive https://manpages.debian.org/testing/devscripts/hardening-check.1.en.html
Perhaps your confusion comes from the fact that it's not in the manual that
hardeningEnable
is additive.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.
With the additional context from @Artturin and @h7x4, I am much more satisfied that the documentation is correct.
I don't think that this change is bad (Artturin showed it didn't decrease security), and I'll leave it to the maintainers to decide if they like the increased explicitness or not.
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.
By grepping for
hardeningEnable
the only settings of it are to either enablepie
or inpkgs/test/cc-wrapper/hardening.nix
.So I think we prefer a single list of hardening flags to be able to change the flags for all platforms at once in case one platform has a broken hardening.