grsecurity forums

...i think with tcpserver, exactly

Filesystem Protections - enabled
[*] Allow special group
(10) GID for special group

Then, for an example, im starting oidentd as user who is member of this special group... and its working. lol, im just starting with linux and i have spent 2 nights searching solution of this rebus...

Now i dont know what i should do with this kind of magic: qmail with deamontool and ucspi-tcp. When i start qmail im finding this lines in logs:

@400000003d924e3a261394dc /usr/local/bin/tcpserver: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory

Is that the same 'problem' as identd? Help... how to up my smtp?

it's probably the no fchdir outside of chroot feature. It breaks all of djb's code. Disable it

-Brad

zan wrote:...i think with tcpserver, exactly

Filesystem Protections - enabled
[*] Allow special group
(10) GID for special group

Then, for an example, im starting oidentd as user who is member of this special group... and its working. lol, im just starting with linux and i have spent 2 nights searching solution of this rebus...

Now i dont know what i should do with this kind of magic: qmail with deamontool and ucspi-tcp. When i start qmail im finding this lines in logs:

@400000003d924e3a261394dc /usr/local/bin/tcpserver: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory

Is that the same 'problem' as identd? Help... how to up my smtp?

Actually this isn't the chroot feature at all
This is a PaX issue. De-pax tcpserver and it'll work just fine. Now if you use vpopmail, you will see even more stuff you'll need to take pax off of.

jMh wrote:Actually this isn't the chroot feature at all
This is a PaX issue. De-pax tcpserver and it'll work just fine. Now if you use vpopmail, you will see even more stuff you'll need to take pax off of.

can you tell me which grsec version this happened to? if it was the latest, an strace output would help a lot.

jMh wrote:This is a PaX issue. De-pax tcpserver and it'll work just fine. Now if you use vpopmail, you will see even more stuff you'll need to take pax off of.

This is the sollution:
chpax -s /var/qmail/bin/qmail-*
That is if your qmail binaries are installed in /var/qmail/bin, as they should. You have to install the chpax utility for this one to work (well, duh).

[quote="flybyThis is the sollution:
chpax -s /var/qmail/bin/qmail-*
That is if your qmail binaries are installed in /var/qmail/bin, as they should. You have to install the chpax utility for this one to work (well, duh).[/quote]
Actually that only fixes the qmail daemons, but until you -s on tcpserver as well, tcpserver still won't start
And for note to all, qmail does need to be stopped when you take pax off, for anyone who hasn't figured that out :-p

PaX Team wrote:can you tell me which grsec version this happened to? if it was the latest, an strace output would help a lot.

It started for me atleast in 1.9.6 when brad removed openwall support and I moved to pax. qmail was one of the first things I noticed breaking.
After turning seg protect off on all qmail daemons, tcpserver, vchkpw and a few other misc things, qmail fired right back up.
If you want I have a box running the current cvs, I can re-enable pax if you like and strace it.
-jeff

jMh wrote:If you want I have a box running the current cvs, I can re-enable pax if you like and strace it.
-jeff

yes please, only the latest release or cvs is relevant, older versions had known bugs (one of the symptoms was what you described, that's why i asked which version you tried).

PaX Team wrote:yes please, only the latest release or cvs is relevant, older versions had known bugs (one of the symptoms was what you described, that's why i asked which version you tried).

Another problem that I've had is the softlimit issue brad discussed with you before, from the grsec messages I was getting.
Is there any plans for the PAX team to fix that?

jMh wrote:Another problem that I've had is the softlimit issue brad discussed with you before, from the grsec messages I was getting.
Is there any plans for the PAX team to fix that?

well, in my opinion that AS resource self-limitation is an application/design problem (if the next glibc grows to twice its current size you'd have the same issue and you would not expect the glibc guys to do something about it...) and therefore we are not going to 'fix' it, however Brad will probably implement something that will lie about the vma mirrors so that they would not be accounted against the address space size limit (i'm not sure if it will work w/o screwing up some other logic elsewhere in the VM, but we'll soon see).

Ah.
Well, I re-enabled pax on everything qmail, and tcpserver starts perfectly now, but now qmail-send is broke
PAX: terminating task: /var/qmail/bin/qmail-send(qmail-send):14475, uid/euid: 1009/1009, EIP: 0804883C, ESP: 5B80E95C
PAX: bytes at EIP: ff 25 1c 18 05 08 68 18 00 00 00 e9 b0 ff ff ff ff 25 20 18
PAX: terminating task: /var/qmail/bin/qmail-send(qmail-send):11509, uid/euid: 1009/1009, EIP: 0804883C, ESP: 5DDA96AC
PAX: bytes at EIP: ff 25 1c 18 05 08 68 18 00 00 00 e9 b0 ff ff ff ff 25 20 18

I'll post an strace in a few minutes, I just wanted to put this out, hehe
flags for qmail-send:
isabel:~# /root/chpax -v /var/qmail/bin/qmail-send

----[ Actual flags for /var/qmail/bin/qmail-send ]----

* Paging based PAGE_EXEC : disabled
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : randomized
* Segmentation based PAGE_EXEC : enabled

I'm running grsecurity-1.9.7d-2.4.19.patch with qmail and djbdns.
I so far haven't experienced any problems.
There are no logs of PaX killing anything and mail delivery works fine.

jMh wrote: * ET_EXEC base : randomized

this is your problem, apparently this djb piece triggers a false positive detection of a return-to-libc style attack. either disable RANDEXEC or recompile/link the executable as ET_DYN (latter is the preferable).

Ahh that would be it.... that's the one option I didn't compile into my kernel, since I compiled everything I didn't trust myself as ET_DYN.

I've just committed code to CVS that doesn't count mirrored vmas against resource limits. See if that fixes your resource limit problems.

-Brad