Skip to content
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

treewide: enable security hardening flags #104091

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

TredwellGit
Copy link
Member

@TredwellGit TredwellGit commented Nov 17, 2020

Motivation for this change

https://blog.fpmurphy.com/2008/06/position-independent-executables.html

PIE is an address space randomization technique that compiles & links executables to be position independent, i.e. machine instruction code that executes properly regardless of where in memory it actually resides. When combined with a kernel that can recognize it is loading a PIE binary, the kernel loads it into a random address instead of the traditional fixed address locations.

https://fedoraproject.org/wiki/Security_Features_Matrix#Address_Space_Layout_Randomization_.28ASLR.29

This makes memory addresses harder to predict when an attacker is attempting a memory-corruption exploit.
To make ASLR effective all segments must be randomized. Leaving the text segment loading address non-randomized reduces the protection provided by the ASLR since the attackers can use ret2text attacks. The loading address of the text segment in a binary can be randomized by building the binary as PIE (Position Independent Executable).

https://fedoraproject.org/wiki/Changes/Harden_All_Packages#Detailed_Harden_Flags_Description

Copy relocations support in GCC 5 and binutils 2.26 makes the performance [decrease] on x86_64 of PIE literally zero for many programs.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
  • Tested execution of all binary files (usually in ./result/bin/)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@ofborg ofborg bot added 6.topic: python 6.topic: stdenv Standard environment labels Nov 17, 2020
@TredwellGit
Copy link
Member Author

Work in progress.

  • Most packages that need to be disabled are because they are required for bootstrapping and the compiler seems to not support PIE. Notably Perl and CPython included. This does not prevent merging, but should be dealt with.
  • What is the best way to build and test all packages? I have nearly rebuilt my personal system with nixos-rebuild build -I nixpkgs=..
  • Haskell is the only merge preventing issue that I have encountered. For example, nix-build -A haskellPackages.hscolour fails to build with errors like can not be used when making a PIE object; recompile with -fPIC. GHC supports PIE and PIC but I am unsure how to get it to work or disable it with how it is packaged. Would really appreciate help with this since it blocks this significant security feature for everything else. @MarcWeber @kosmikus @peti @lostnet
  • I am also investigating enabling stack clash protection. If this pull request is blocked for long by the Haskell issue, then I might just include that as well to prevent rebuilds.

@TredwellGit
Copy link
Member Author

Wonder if issues are caused by this: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4287

@lostnet
Copy link
Contributor

lostnet commented Nov 20, 2020

I've quite possibly missed conversation on this elsewhere, but if not, I think would be good to test with haskell.packages.ghc901.hscolour as the haskell commit can be easily applied as a patch to 9.0, i.e. I think this would be ok. But the first round of compiling hscolour would be in the bootstrap, using an 8.10.2 binary compiled for debian/ubuntu, so it would probably need to be compiling without pie in that phase.

I'm not really sure what it working in 9.0+patch would mean for the 8.X versions that are the current default as haskell.org seems to only have marked it for 9, also, I'm not optimistic for what will happen with aarch64 as it seems quite a bit more sensitive to relocation problems.. But some version(s) on some platform(s) would be a great start.

@TredwellGit
Copy link
Member Author

TredwellGit commented Nov 20, 2020

Thanks for responding.

I've quite possibly missed conversation on this elsewhere

You did not.

But the first round of compiling hscolour would be in the bootstrap, using an 8.10.2 binary compiled for debian/ubuntu, so it would probably need to be compiling without pie in that phase.

That is the problem. I am unsure how to disable it because hardeningDisable = [ "pie" ]; is not respected in https://github.com/NixOS/nixpkgs/tree/staging/pkgs/development/compilers/ghc or https://github.com/NixOS/nixpkgs/tree/staging/pkgs/development/haskell-modules.

@lostnet
Copy link
Contributor

lostnet commented Nov 20, 2020

That is the problem. I am unsure how to disable it because hardeningDisable = [ "pie" ]; is not respected in https://github.com/NixOS/nixpkgs/tree/staging/pkgs/development/compilers/ghc or https://github.com/NixOS/nixpkgs/tree/staging/pkgs/development/haskell-modules.

Booting the stage1 of the real ghc is probably going to need these settings for ghc itself not to fail as a PIE with the binary libraries(?), but before, when the bootstrap ghc is setting up its bootPkgs (and then after the real ghc is built and is building its package set) I think you need to override the haskell-modules side, which should go from make-package-set.nix to generic-builder

@TredwellGit
Copy link
Member Author

Upon further investigation, I have determined that GHC's support for PIC and PIE is bad. I have it working with PIE totally disabled for Haskell; will push later with additional security hardening enabled.

@TredwellGit TredwellGit changed the title treewide: enable position independent executables (PIE) treewide: enable security hardening flags Nov 25, 2020
@utsl42
Copy link
Contributor

utsl42 commented Nov 25, 2020

See also #101666 (comment)
There were some past issues referencing ghc using gold, so that may have some relevance to what you're trying to do.

@TredwellGit
Copy link
Member Author

Hydra x86_64 Linux seems available so I pushed an update. Would prefer if we could let this build with very low priority rather than cancelling it because otherwise it is difficult to work on.

@TredwellGit
Copy link
Member Author

@vcunat, please add "i686-linux" to supportedSystems for https://hydra.nixos.org/jobset/nixpkgs/hardening-flags#tabs-configuration.

@vcunat
Copy link
Member

vcunat commented Apr 21, 2021

I set up the default value, as i686 isn't (fully) supported anymore. Anyway, there's probably some evaluation problem, but on a quick look I can't see what it is.

https://blog.fpmurphy.com/2008/06/position-independent-executables.html
>PIE is an address space randomization technique that compiles & links executables to be position independent, i.e. machine instruction code that executes properly regardless of where in memory it actually resides. When combined with a kernel that can recognize it is loading a PIE binary, the kernel loads it into a random address instead of the traditional fixed address locations.

https://fedoraproject.org/wiki/Security_Features_Matrix#Address_Space_Layout_Randomization_.28ASLR.29
>This makes memory addresses harder to predict when an attacker is attempting a memory-corruption exploit.
>To make ASLR effective all segments must be randomized. Leaving the text segment loading address non-randomized reduces the protection provided by the ASLR since the attackers can use ret2text attacks. The loading address of the text segment in a binary can be randomized by building the binary as PIE (Position Independent Executable).

https://fedoraproject.org/wiki/Changes/Harden_All_Packages#Detailed_Harden_Flags_Description
>Copy relocations support in GCC 5 and binutils 2.26 makes the performance [decrease] on x86_64 of PIE literally zero for many programs.
@TredwellGit
Copy link
Member Author

i686 works without issue.
@vcunat, can we add "aarch64-linux" and/or "x86_64-darwin"?

@vcunat
Copy link
Member

vcunat commented Apr 26, 2021

OK, they were quite free now so I added them, i.e. now it's full as the default nixpkgs/trunk jobset.


At some point it would be nice to separate the common (stdenv) changes from the package changes, I think, for better visibility.

@Mic92
Copy link
Member

Mic92 commented May 24, 2021

With this PR also static-pie will work: #123989

@r-burns
Copy link
Contributor

r-burns commented Oct 8, 2021

If this gets revived at some point (I hope it does!) be sure to take a second look at any packages which needed hardening disabled; many should be fixed by #135619.

@r-burns
Copy link
Contributor

r-burns commented Oct 26, 2021

Oh, I just realized I could revive this myself since the hydra job is still active - I'd just have to push to this branch. Would that be all right with you? Don't want to step on any toes

@TredwellGit
Copy link
Member Author

I am working on rebasing and writing documentation for this, but I have been hesitant to push because I do not want to overload Hydra given the work for 21.11.

@vcunat
Copy link
Member

vcunat commented Oct 26, 2021

Since several days ago there's also the caveat that cancelling whole evaluations doesn't work (and restarting individual jobs doesn't work).

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/where-did-you-get-stuck-in-the-nix-ecosystem-tell-me-your-story/31415/6

@wegank wegank added 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 2.status: merge conflict labels Mar 19, 2024
@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet