What does enabling grsecurity in Firefox and Chromium do? And what's the effect on systems that don't have grsecurity enabled?

The patches I wrote just disable the PAX_MPROTECT feature for the firefox, firefox's pluginwrapper and chromium binaries (you can see what PAX_MPROTECT does here: http://pax.grsecurity.net/docs/mprotect.txt , but basically, it prevents code execution in a variety of situations).

We need to disable this feature for these binaries when running grsecurity kernels, otherwise the kernel will kill these processes when they are starting up, as these binaries do JIT code execution as part of their normal operation (Java will also need this, BTW, but I haven't had time to do it yet).

We disable the feature by running "paxctl -c -m" on the binary, which converts an ELF section into a format expected by PaX (I don't know the exact details) and then disables the PAX_MPROTECT flag. This is what Gentoo hardened does as well, BTW.

However, paxctl is only ran when nixpkgs.config.grsecurity is true, so on non-grsecurity enabled systems (i.e. by default) my patch doesn't change anything in Firefox and Chromium compilation.

The only noteworthy but minor exception is that in Chromium, now we explicitely compile mksnapshot before compiling chrome, instead of compiling it implicitely, but this shouldn't have any effect in the result.

Added a new patch, which allows some KDE applications to run as well.

@wizeman, what effect do these changes have on systems that don't use grsecurity? Are there any performance or usability impacts?

@peti There should be no noticeable negative impact for systems that don't use grsecurity.

As for Firefox and Chromium, paxctl is only ran when nixpkgs.config.grsecurity is true. If it's false (the default) we don't modify the binaries.

As for the qimageblitz patch, it's just declaring that the stack does not contain executable code. On non-grsecurity systems, it should behave the same in terms of performance and functionality, except you may have better protection against exploits on programs that use this library if your CPU supports the NX bit (as most x64 CPUs do).

Added the grsecurity patch for 3.11.x kernels (the latest stable).

+1

Updated grsecurity patches to latest versions.

Added support for polkit, whose latest version now includes a Javascript JIT compiler (sigh...)

Fixed firefox changes due to master removing 'let optional = stdenv.lib.optional' definition
Added compilation fix for 'spl' kernel package

Updated to latest grsec patches

I think that the PaX marking phases should be run always (regardless of the option). It's supposed just to set some flags in ELF and have no effect if you don't run a supporting kernel. Now most of X-depending stuff has a changed hash if you specify the option (e.g. through polkit).

@vcunat I'm fine with that.

BTW, we also need to PaX mark a couple of gcc binaries for -RANDMMAP, otherwise gcc will segfault when using precompiled headers (I have a patch for this, but I'm still testing it).

Does that mean 'paxctl' will need to be included in bootstrap-tools, in order to build gcc? What if we leave it as an option, would we still need to include it in bootstrap-tools?

Rebased and factored out grsecurity patch updates into a separate pull request.
Also updated gradm to latest version.

Bootstrap-tools inclusion: I haven't investigated deeper, but I think we won't need that (apart from the fact that bootstrapping on PaX-enabled systems doesn't seem a priority). It should be enough to mark the needed files from bootstrap-tools by paxctl (i.e. update gcc in bootstrap-utils). Then this version of gcc can be used to build paxctl and use it in the bootstrapping process. I would also think that there is a catch in compiling gcc on PaX-enabled kernel -- maybe it will be necessary to mark files during the build process.

• Changed the code to always pax mark executables, as suggested.
• Now we also explicitly set all flags with paxctl.
• Changed paxctl to be a native build input, rather than a regular build input.
• Added pax markings for llvm, gcc, oraclejdk7, spidermonkey and gstreamer.

@vcunat It's not a problem to compile gcc on a PaX-enabled kernel, that's what I did before it was properly PaX-marked.

If not properly marked, gcc only segfaults under a PaX kernel when using precompiled headers, and AFAICT gcc does not use that feature when compiling itself.

What's the status of this? Update to apply and merge these markings on those packages (whether with grsecurity kernels or not)?

@vcunat Please don't merge it yet, instead I prefer to merge some improvements that I have made in my personal tree, and I also want to make a few more (mostly to reduce duplicate code). As soon as I finish I will update this pull request and add a comment to let you know.

If you wish, feel free to close this pull request in the mean time.

I wouldn't merge it, as it doesn't apply anyway. I think it's better to remain in this thread.

I've rebased and added a few more changes and fixes, most importantly:

• Added a new stdenv.needsPax function, which currently returns the same as stdenv.isLinux
• Added a paxmark function to reduce duplicate code
• Fixed the haskell compiler to mark stacks as non-executable

One significant problem is that under PaX/grsecurity, mesa needs to use a readonly text segment for libGL, however, it looks like it causes a slight performance degradation.
Therefore, I've only enabled it if config.grsecurity is true, but this causes mesa and everything dependant on mesa (such as everything dependant on X, perhaps?) to be recompiled if you enable config.grsecurity... I'm not sure what's the best way to handle this, though...

I'm still in the process of testing these changes, but I've updated the pull request now because it seems that @thoughtpolice is also working on grsecurity and I want to spare him from again duplicating work that I've already done... :-)

Mesa: only the libGL found in /run/opengl-drivers* is ever used, and that symlink often differs from what's the original linkage. I suggest we only change that one and the one in build deps can be in any state (e.g. marked, slow one). I'll do this change after I get some time to review the rest and merge it.

This is a stdenv-changing thing anyway, and I think it will be better to let Hydra rebuild before merging it. Can someone create a job(set) for this PR? @edolstra ?

I just pushed a minor bugfix, sorry... In file pkgs/development/compilers/jdk/jdk7-linux.nix:

     74       ${paxmark "m" "$file"}
     75       # On x86 for heap sizes over 700MB disable SEGMEXEC and PAGEEXEC as well.
     76       ${stdenv.lib.optional stdenv.isi686 (paxmark "sp" "$file")}

I changed line 76 to:

     76       ${stdenv.lib.optional stdenv.isi686 (paxmark "msp" "$file")}

Because paxmark is not accumulative, it's idempotent...

I wonder if it would also make sense to add paxctl to Linux's stdenv so that we don't need to add paxctl to nativeBuildInputs all the time...

OK, current updates: the Hydra job for pr-1187 seemed to go through fairly smoothly, but it wasn't the full build. I have now rebased this branch on top of the current master, and it is available in grsec-stdenv.

Shea will run a full Nixpkgs build soon.

PaX marking cannot be disabled with nixpkgs.config? One may not want pax, and use some other security frameworks.

PaX markings have no effect when grsecurity is disabled.
On May 20, 2014 10:42 AM, "lethalman" [email protected] wrote:

PaX marking cannot be disabled with nixpkgs.config? One may not want pax,
and use some other security frameworks.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1187#issuecomment-43651013
.

@lethalman As @fread2281 said, PaX markings in binutils have no affect on non-grsecurity kernels. The problem is paxctl needs to rewrite the ELF header slightly to be compatible when you mark it so grsec can recognize it, so you must mark things at installation time - but doing so changes the output binary, and thus the results. That means if PaX markings were optional, you couldn't use Hydra to get binary builds - you'd have to build the binaries and mark yourself, which is fairly hostile to a lot of users.

The binutils changes mean that expressions will now only need to have the right flags set ELF header in the expression via paxctl, they do not need to be marked or rewritten, and GCC will correctly emit the right ELF headers for PaX out of the box. The patches come from Hardened Gentoo and should be quite stable. But of course, this will require a full stdenv update for Linux.

Added to my stdenv choice again. IIRC it was only "untestedness" that was blocking merge right before release.