grsecurity forums

Hey,

not once was I required to disable individual features on a per-file basis.

Since I also don't want to mark all the binaries by hand (sounds stupid, am I missing something?) I typically enable CONFIG_PAX_EI_PAX and be done with it. However, this seems pointless given that (in my case) this functionality is not required or (most likely) ever will be.

Is it nontrivial to offer an option to disable this stuff completly?

i guess yours is a special situation that hasn't come up before, i wonder what you're using your system for if you can get away without relaxing any PaX feature . in any case, the no-per-file-control case is supportable but doing it right requires more than just a few lines of change as mm->pax_flags would have to go altogether. since i'm looking into this feature control anyway (for xattr support), i'll see if i can easily implement this but i make no promises.

Thanks for the reply. I'm not sure if It's worth wasting your time If everyone needs that anyway.

But I certainly can't be the only one who doesn't make use of it. What are the typical offenders out there on a non-desktop box?
I assume that (temporary?) RWX mappings are the biggest culprit?

Lox wrote:What are the typical offenders out there on a non-desktop box? I assume that (temporary?) RWX mappings are the biggest culprit?

the conflicting programs have changed over the years but the underlying reasons didn't, it's either runtime code generation prevention or ASLR that programs run afoul of.

for the former category, it used to be (read: decade ago ) nested function trampolines (in glibc support code itself, IIRC, localegen?, nowadays we have grub2, etc) and all sorts of runtime codegen (the old X server module loader, java, then came various multimedia related libraries with text relocations, 3D engines, etc). what would bit one even on a server was mostly java (think tomcat) and text relocations but lately it's also bad glibc code that wants to modify RELRO segments later (due to another broken feature, GNU_STACK).

for ASLR the only conflicts i know of were due to incorrect programmer assumptions about the behaviour of hinted mmap, first the old glibc linuxthreads library (since replaced with NPTL) then lately jemalloc (used mostly in firefox et al. i think, the fixed version has yet to be imported into firefox though) and gcc (PCH support code assumes that certain parts of the address space are always available).