pax and grsecurity things..

[devastor]

Hi,

I've got a little problem with chpax and some logging issues with pax and grsec
(grsec-1.9.8-rc1, gradm for it and probably the newest chpax)

When I try to view or set flags for some programs using chpax
I just get error Bad file descriptor (in admin mode and only for some files):

# chpax -v /usr/sbin/sshd
/usr/sbin/sshd: Bad file descriptor
#file /usr/sbin/sshd
/usr/sbin/sshd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Any ideas?

Also pax for some reason kills some of my programs and i only get
"PAX: terminating task: ..." to the logs.. It would be great it if gave a bit more
information about what happened and why pax killed it.. Now it's hard to tell if the
program does something wrong (ie. buffer overflow) or if pax does something wrong
(bad configuration, etc)
I tried to disable all the flags too, but the program was still terminated..

What do you think?

Then to grsec:

grsec: From x.x.x.x: attempt to open .. for reading by (updatedb:23092) UID(0) EUID(0), parent (slocate:17401) UID(0) EUID(0)

hm. "attempt to open .."
that doesn't tell too much.. maybe an inode should be shown there too?
(If there's an easy way to figure it out)

--
Tuomas silen

[spender]

as for the chpax problem, kill sshd first. The new version of chpax doesn't have very good error reporting in that regard. (You can't write to it because it's got VM_MAYNOTWRITE, which prevents you from overwriting the binary while its running)

-Brad

[PaX Team]

# chpax -v /usr/sbin/sshd
/usr/sbin/sshd: Bad file descriptor
#file /usr/sbin/sshd
/usr/sbin/sshd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

besides the problem with incorrect error reporting, the real reason is what Brad mentioned already (well, almost : chpax wants to write to the given binary which is not possible if it is running as an executable (which means that the kernel mmap()'ed it with VM_DENYWRITE). so you have to temporarily kill/stop the given service, chpax then restart it (which you'd have to do anyway since the PaX flags take effect on execution only, this will be true even in the future where you can specify them in the ACL system). btw, you should try out the ET_DYN version of sshd, i think it's a critical enough service to deserve it.

Also pax for some reason kills some of my programs and i only get
"PAX: terminating task: ..." to the logs.. It would be great it if gave a bit more
information about what happened and why pax killed it.. Now it's hard to tell if the
program does something wrong (ie. buffer overflow) or if pax does something wrong
(bad configuration, etc)
I tried to disable all the flags too, but the program was still terminated..

PaX kills a process for one reason only: when it tried to execute code from a non-executable area (and that's never a false positive, i.e. there's nothing that could be wrong with that). also, the error message does give you more information, there's a second line that shows some memory context, it'd help if you posted both lines here. what makes it strange in your case is that you say that after having disabled the PaX flags it was still killed (by PaX, presumably). that's impossible given the program (PaX) logic, so i'd like to know every detail to reproduce it.

[devastor]

besides the problem with incorrect error reporting, the real reason is what Brad mentioned already (well, almost icon_wink.gif: chpax wants to write to the given binary which is not possible if it is running as an executable (which means that the kernel mmap()'ed it with VM_DENYWRITE). so you have to temporarily kill/stop the given service, chpax then restart it (which you'd have to do anyway since the PaX flags take effect on execution only, this will be true even in the future where you can specify them in the ACL system). btw, you should try out the ET_DYN version of sshd, i think it's a critical enough service to deserve it.

Thanks, that indeed was the problem.. And I'll try that ET_DYN version, too

PaX kills a process for one reason only: when it tried to execute code from a non-executable area (and that's never a false positive, i.e. there's nothing that could be wrong with that). also, the error message does give you more information, there's a second line that shows some memory context, it'd help if you posted both lines here. what makes it strange in your case is that you say that after having disabled the PaX flags it was still killed (by PaX, presumably). that's impossible given the program (PaX) logic, so i'd like to know every detail to reproduce it.

Ah, right..I think I found out the problem.. looks like an user error after all

I first disabled Paging based PAGE_EXEC for the program and checked out that it was
disabled and then i disabled other flags, including Segmentation based PAGE_EXEC
and checked out that it was disabled, too..
But i didn't notice that when I disabled Segmentation based PAGE_EXEC with -s it
at the same time enabled Paging based PAGE_EXEC again for some reason
Looks like there were either one of those enabled every time i ran it..
both weren't disabled at the same time

Are those two somehow conflicting or is there some other reason why disabling one
sometimes enables the other one?

And now that I finally managed to disable both of them, and tried the program
it indeed did segmentation fault (No idea why it still would try to execute code from a
non-executable are, unless segmentation faults always do that, though)
Anyway. looks like pax did exactly what it was supposed to do..

Here are those lines from dmesg anyways, probably no need for them now, though..
First two lines came when i ran it through xinetd, and other two when i ran it in standalone
mode.. strange that there's no "From x.x.x.x" when it's ran in standalone mode?

PAX: From x.x.x.x: terminating task: /usr/sbin/sshd2(sshd2):24602, uid/euid: 3243/3243, EIP: 401686C8, ESP: BFFFE2C0
PAX: bytes at EIP: c0 86 16 40 c0 86 16 40 10 11 11 08 10 11 11 08 b8 11 11 08

PAX: terminating task: /usr/sbin/sshd2(sshd2):23543, uid/euid: 3243/3243, EIP: 401686D8, ESP: BFFFECD0
PAX: bytes at EIP: d0 86 16 40 d0 86 16 40 18 f0 10 08 18 f0 10 08 e0 86 16 40

[devastor]

btw. when I apply ET_DYN patch to for example sshd, is it automatically enabled when
the program is ran, or does it replace ET_EXEC so that i should still enable ET_EXEC?

[PaX Team]

I first disabled Paging based PAGE_EXEC for the program and checked out that it was disabled and then i disabled other flags, including Segmentation based PAGE_EXEC and checked out that it was disabled, too..
But i didn't notice that when I disabled Segmentation based PAGE_EXEC with -s it at the same time enabled Paging based PAGE_EXEC again for some reason
Looks like there were either one of those enabled every time i ran it..
both weren't disabled at the same time

Are those two somehow conflicting or is there some other reason why disabling one sometimes enables the other one?

hmm, i can at least partly explain the above , here's the story: the two non-exec features are controlled by two bits in the ELF header. their default value (that is, when the standard toolchain such as ld creates an ELF executable) is 0 which is interpreted as 'enabled' by PaX (that is, we chose the secure by default approach). historically there was PAGEEXEC first and later SEGMEXEC however the two methods are mutually exclusive so when faced with an ELF header having two 0s in those bits (which is the default case unless someone played with chpax already) we had to make a choice in their interpretation. since SEGMEXEC is the faster version and also the newer one (needing more user feedback if it breaks something , we chose to have SEGMEXEC override PAGEEXEC. so chpax would tell you that the former is enabled and the latter is disabled (which is true from a behaviorial point of view since this is what the kernel will do) even if technically both bits say 'enable' (maybe in this case PAGEEXEC should be reported as 'overriden' and not 'disabled'?). now this will have a sideeffect when the unsuspecting user disables SEGMEXEC on the binary as it will leave PAGEEXEC enabled (after all he didn't say to disable that), apparently coming out of the blue - but now you at least know why .

so how does this relate to your situation above? if you didn't actually disable PAGEEXEC first (with -p) just verified it with -v (and thought it was disabled) then the above happened, otherwise i have no idea, a -p -s sequence should have disabled both of them for good.

And now that I finally managed to disable both of them, and tried the program it indeed did segmentation fault (No idea why it still would try to execute code from a non-executable are, unless segmentation faults always do that, though) Anyway. looks like pax did exactly what it was supposed to do..

was it a segfault (SIGSEGV signal) or a SIGKILL by PaX? if the latter, then i can't possibly imagine what happened, PaX simply cannot kill anything if the two non-exec features are disabled (check the code in arch/i386/mm/fault.c and you will see that pax_report_fault() can be called only when either of them is enabled).

Here are those lines from dmesg anyways, probably no need for them now, though..
First two lines came when i ran it through xinetd, and other two when i ran it in standalone
mode.. strange that there's no "From x.x.x.x" when it's ran in standalone mode?

the IP address is reported when it is known to grsec. it's Brad's addition, he can probably explain it better. as for the actual info, it looks really weird, if you look at the dumped data as little endian dwords, you will recognize them as some kind of addresses (GOT?) and i can't possibly imagine who would want to execute them (instead of dereferencing). if you want, you can do some debugging and see which library this EIP value is in then single step the code and see who transfers control to that area.

[PaX Team]

btw. when I apply ET_DYN patch to for example sshd, is it automatically enabled when the program is ran, or does it replace ET_EXEC so that i should still enable ET_EXEC?

the ET_DYN patch produces an executable in a different format so it will be 'enabled' as soon as you run it (what will actually be enabled is randomization of the main executable). both ET_EXEC and ET_DYN are ELF formats not PaX features so you don't really enable/disable them but rather create one or the other (the default format for executables being ET_EXEC and for libraries ET_DYN and the ET_DYN patch forces the latter for executables as well, this allows them to be relocated).