SUSE Linux 9.1 doesn't work with grsecurity patch!?

[capricious]

Hello,

the new SUSE 9.1 does not work with a vanilla kernel 2.6.5 patched with grsecurity-2.0-2.6.5.patch.
Same problem with 2.6.4 and the belonging grsec-patch.
I can find some errors in the logs like:
login[13608]: PAM [dlerror: libxcrypt.so.1: cannot enable executable stack as shared object requires: Permission denied]
I have no special rules or RSBAC usage like before in my SUSE 9.0. With SUSE 9.0 it works fine.
Any ideas how to solve this problem?

bye

[PaX Team]

I can find some errors in the logs like:
login[13608]: PAM [dlerror: libxcrypt.so.1: cannot enable executable stack as shared object requires: Permission denied]
I have no special rules or RSBAC usage like before in my SUSE 9.0. With SUSE 9.0 it works fine.
Any ideas how to solve this problem?

http://forums.grsecurity.net/viewtopic.php?t=717

[capricious]

I can find some errors in the logs like:
login[13608]: PAM [dlerror: libxcrypt.so.1: cannot enable executable stack as shared object requires: Permission denied]
I have no special rules or RSBAC usage like before in my SUSE 9.0. With SUSE 9.0 it works fine.
Any ideas how to solve this problem?

http://forums.grsecurity.net/viewtopic.php?t=717

Mmh,
the libs in SUSE 9.0 have no STACK Header like in SUSE 9.1:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x0a399 0x0a399 R E 0x1000
LOAD 0x00a3a0 0x0000b3a0 0x0000b3a0 0x01328 0x2853c RW 0x1000
DYNAMIC 0x00b554 0x0000c554 0x0000c554 0x000d8 0x000d8 RW 0x4
STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Does the nul-addresses in STACK-line tell me that the stack is unused?

Is it a bug if there is such a header?

But it is not the only failure...
For testing I have disabled PAX in a new kernel and now filesystems are mounted readonly.
There is no other error on screen and I have no log entries because of readonly filesystems ;(

Is it possible to use grsec with SUSE 9.1 without beeing a kernel hacker and without rebuilding the whole system?

[PaX Team]

STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Does the nul-addresses in STACK-line tell me that the stack is unused?

what matters in that line is the access rights field, in this case RWE. that indicates the need for an executable stack, so when ld.so maps that library it will also try to make the stack executable and that won't work on a properly setup PaX system (i.e., with MPROTECT on).

Is it a bug if there is such a header?

not a bug, it just means that the given library/executable was created with a recent toolchain (gcc/ld) that emits the PT_GNU_STACK program header. if i recall correctly, ld.so will assume an executable stack for such libraries if mixed in a process with libraries that don't have such a program header.

Is it possible to use grsec with SUSE 9.1 without beeing a kernel hacker and without rebuilding the whole system?

that's a question only SUSE can answer...

[capricious]

it just means that the given library/executable was created with a recent toolchain (gcc/ld) that emits the PT_GNU_STACK program header. if i recall correctly, ld.so will assume an executable stack for such libraries if mixed in a process with libraries that don't have such a program header.

If I understand, the execution option is set because there are not enough information about correct options in build process. So it simply puts in all options to be "safe". Is this right?

Can you say that it is a failure that the exec bit is set in stack header?
Can you say that the libraries are defect if the exec bit is set when it is not needed?
So can you say that SUSE people has done something wrong in the build process?

that's a question only SUSE can answer...

SUSE wants to get paid for the answer.

[PaX Team]

If I understand, the execution option is set because there are not enough information about correct options in build process. So it simply puts in all options to be "safe". Is this right?

well, yes and no, depending on which part of the build process we're talking about. the PT_GNU_STACK stuff is affected by three components: gcc (as in, compiler), 'as' (the assembler) and ld (the linker). the first two are responsible for producing object files with the appropriately flagged .note.GNU-stack section. normally gcc does the job properly as it will request an executable stack only when it knows that the given code uses a nested function trampoline (of course it assumes gcc 3.3.x, older gcc versions won't emit .note.GNU-stack, see below how ld handles that). now on the other hand 'as' is not that smart and cannot deduce from the assembly code whether an executable stack will be needed, so unless the code itself emits/specifies a .note.GNU-stack section or 'as' is forced one way via command line switches, 'as' won't emit one itself - you could call this a 'to be safe' option because of how ld will handle it. finally comes ld that produces an executable/library and emits a PT_GNU_STACK program header based on all the .note.GNU-stack sections in the object files. the rule here is again that you could call 'to be safe', that is, PT_GNU_STACK will request an non-executable stack if every single object file had a non-executable .note.GNU-stack section. so if an object file is missing this section or has an executable one, the end result will be an executable PT_GNU_STACK.

Can you say that it is a failure that the exec bit is set in stack header?

by itself, no.

Can you say that the libraries are defect if the exec bit is set when it is not needed?

well, 'defect' is a relative term, from a security point of view it is a defect, otherwise it doesn't (shouldn't) affect anything.

So can you say that SUSE people has done something wrong in the build process?

well, if there's anything 'wrong' in their build process then it's that they may not have manually verified each library that had an executable stack request. but even then you'd end up with libraries that do need an executable stack because they generate nested function trampolines.

[capricious]

well, if there's anything 'wrong' in their build process then it's that they may not have manually verified each library that had an executable stack request. but even then you'd end up with libraries that do need an executable stack because they generate nested function trampolines.

Ok, SUSE people are victims of a bad choice of library/package version combinations... I think no distributor will check every library...
So it is some kind of lucky chance if the grsecurity/PAX patch will work with a GNU basesystem, isn't it?

Can I use that paxctl tool to allow those exec stack libraries?
I've never used or installed it before, only patched the kernel to have more security on code execution and more privacy (proc limitations).
Is there a way to find out all libs/execs which won't work right now without testing by hand.

Thanks a lot

[PaX Team]

Ok, SUSE people are victims of a bad choice of library/package version combinations... I think no distributor will check every library...
So it is some kind of lucky chance if the grsecurity/PAX patch will work with a GNU basesystem, isn't it?

i wouldn't call it 'chance', we know exactly what combinations of glibc/PaX features work/fail. basically, everyone (meaning distros) using glibc CVS of the past half year or so have PT_GNU_STACK support in the form of the infamous make_stack_executable() function in ld.so, so users of those systems can either run without MPROTECT (disabled in the kernel or on individual executables) which is bad for security of course or patch that function like gentoo did: http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/files/2.3.3/glibc-2.3.3-dl_execstack-PaX-support.patch.

Can I use that paxctl tool to allow those exec stack libraries?

i guess your userland doesn't use the patched binutils so what you'd need instead is chpax (and of course EI_PAX support in the kernel), then chpax -m all affected executables (not libraries).

Is there a way to find out all libs/execs which won't work right now without testing by hand.

for some time now the prelink package comes with a tool called execstack which can query the state of PT_GNU_STACK, alternatively you can just use readelf -l and look for the STACK line.