grsecurity forums

How to temporarily disable security features PAX?

Theoretically, I have the kernel PAX_SOFTMODE, but turning softmodem by systtl does not produce any result.

It is so annoying that during the compilation of various programs - such as VirtualBox, the installer tries to run different scripts in the source program compiled and PAX block such attempts.

The problem arose when the system have changed the labeling of PT_PAX to XT_PAX, a few months ago.
Earlier pax_softmode switched aggressive Pax functions if necessary.

My configuration:

Code: Select all

CONFIG_PAX_KERNEXEC_PLUGIN=y
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_PAX_USERCOPY_SLABS=y
CONFIG_PAX=y
CONFIG_PAX_SOFTMODE=y
CONFIG_PAX_EI_PAX=y
# CONFIG_PAX_PT_PAX_FLAGS is not set
CONFIG_PAX_XATTR_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_MPROTECT_COMPAT=y
CONFIG_PAX_ELFRELOCS=y
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_BTS=y
# CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="bts"
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_STRUCTLEAK=y
# CONFIG_PAX_MEMORY_UDEREF is not set
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_CONSTIFY_PLUGIN=y
CONFIG_PAX_USERCOPY=y
# CONFIG_PAX_USERCOPY_DEBUG is not set
CONFIG_PAX_SIZE_OVERFLOW=y
CONFIG_PAX_LATENT_ENTROPY=y

Code: Select all

sysctl -a | grep pax
kernel.pax.softmode = 0

Paxtest blackhat:

Code: Select all

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 29 bits (guessed)
Heap randomisation test (ET_EXEC)        : 23 bits (guessed)
Heap randomisation test (PIE)            : 35 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 27 bits (guessed)
Shared library randomisation test        : 29 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 35 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 35 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Killed
Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE)         : Killed

Good result.

Turn off the Pax (pax_softmode):

Code: Select all

sysctl -w kernel.pax.softmode=1
kernel.pax.softmode = 1

Paxtest blackhat:

Code: Select all

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 29 bits (guessed)
Heap randomisation test (ET_EXEC)        : 23 bits (guessed)
Heap randomisation test (PIE)            : 35 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 27 bits (guessed)
Shared library randomisation test        : 29 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 35 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 35 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Killed
Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE)         : Killed

Mprotect restrictions are further on, but before moving to XT_PAX marking softmodem mode turn off these restrictions.

Is this the correct behavior Pax now, or maybe a bug?
Is there any chance that in time the system was the ability to temporarily disable Pax?

Patches?
All 3.11.x.
Linux - Vanilla-sources + Grsecurity + FBcondecor.
Os: Gentoo Hardened x86_64.

Code: Select all

gcc version 4.6.3 (Gentoo Hardened 4.6.3 p1.13, pie-0.5.2)

Code: Select all

gcc version 4.7.3 (Gentoo Hardened 4.7.3-r1 p1.3, pie-0.5.5)

Cheers

softmode works fine, i think you're mixing up something. first, you have CONFIG_PAX_HAVE_ACL_FLAGS enabled so grsec's RBAC system has final say over the PaX process flags. second, paxtest itself sets the PaX flags according to the given test even under softmode (i.e., for the paxtest binaries the PaX flags are overridden from the default, this is on purpose of course). last but not least, PaX doesn't affect script execution, so maybe just post your error logs (kernel logs included if any) so that we can have a better idea about what exactly failed for you.

From 2 years I have just set PAX_ACL in the kernel :

Code: Select all

CONFIG_PAX_HAVE_ACL_FLAGS = y

At a time when I used PT_PAX marking, mode switched to a similar ailment softmode Pax, even in the test paxtest could see the security mprotect be canceled with a softmode.

When I changed the labeling system from PT_PAX to XT_PAX , softmode not exclude Pax so that , in effect, as they attempt to install a program ( compile - Gentoo) , there is often the problem :

Code: Select all

 sysctl -a | grep pax
kernel.pax.softmode = 1

Code: Select all

[ 6615.986460 ] grsec : denied RWX mprotect of / lib64/ld-2.15.so to / var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/.tmp_out [ . Tmp_out : 7815 ] uid / euid : 0/ 0 gid / egid : 0/ 0, parent / var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/configure [ configure: 6283 ] uid / euid : 0/ 0 gid / egid : 0/ 0
[ 6615.986471 ] show_signal_msg : 63 callbacks suppressed
[ 6615.986476 ] . Tmp_out [ 7815 ]: segfault at 31649006151 ip 00000316485efbf2 sp 000003f50d7605c0 error 7 in libGL.so.325.15 [ 31,648,548,000 + D9000 ]
[ 6615.986494 ] grsec : Segmentation fault occurred at 0000031649006151 in / var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/.tmp_out [ . Tmp_out : 7815 ] uid / euid : 0 / 0 gid / egid : 0/ 0, parent / var/tmp/portage/app-emulation/virtualbox-4.2.18/work/VirtualBox-4.2.18/configure [ configure: 6283 ] uid / euid : 0/ 0 gid / egid : 0/ 0

Or this error:

Code: Select all

[ 8477.833128] grsec: denied RWX mprotect of /lib64/ld-2.15.so by /var/tmp/portage/x11-libs/vte-0.34.2/work/vte-0.34.2/src/tmp-introspectwz3_0K/.libs/Vte-2.90[Vte-2.90:8148] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/g-ir-scanner[g-ir-scanner:7990] uid/euid:0/0 gid/egid:0/0
[ 8477.833139] show_signal_msg: 291 callbacks suppressed
[ 8477.833144] Vte-2.90[8148]: segfault at 2f2271c4151 ip 000002f220ebcbf2 sp 000003fa6444f160 error 7 in libGL.so.325.15[2f220e15000+d9000]
[ 8477.833164] grsec: Segmentation fault occurred at 000002f2271c4151 in /var/tmp/portage/x11-libs/vte-0.34.2/work/vte-0.34.2/src/tmp-introspectwz3_0K/.libs/Vte-2.90[Vte-2.90:8148] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/g-ir-scanner[g-ir-scanner:7990] uid/euid:0/0 gid/egid:0/0

For this reason, each upgrade I have to use a kernel without grsec / pax .
The problem is directly related to the migration of the PT -PAX on the XT- PAX .
Earlier sufficient to turn pax_softmode - and all of the programs compile without such surprises.

In connection with this, I wanted to ask if you can somehow by sysctl temporarily constrain the grsec / pax, so as not to block the action portage at compile time?

Cheers

Have you set PAX_MARKINGS="XT" in your make.conf?
If you don't do that portage will only use PT markings, which will lead to such errors.
I'm not sure if virtualbox works at all though.
For me pax works fine without softmode...

N8Fear wrote:Have you set PAX_MARKINGS="XT" in your make.conf?
If you don't do that portage will only use PT markings, which will lead to such errors.
I'm not sure if virtualbox works at all though.
For me pax works fine without softmode...

Code: Select all

grep PAX /etc/portage/make.conf
PAX_MARKINGS="XT"

The portage PAX_MARKING takes place during the installation, and I have the problem with different tests, which are performed at compile time, long before the start PAX_MARKING.

The solution would be to temporarily disable PAX protect the location of $ PORTAGE_TMPDIR, or temporarily disable PAX security throughout the system.
In the example cited earlier configure script from virtualbox testing the performance of the compiler, in the second example at compile time vde test is performed introspection-test - what does make already at compile time.

pax.eclass simply is not able to cover such cases.

Currently, the only option is to build, while the system is running on the kernel without pax.
But is this the only possible solution?

I'm using KVM and therefore have no experience with virtualbox. I'm quite sure that I have build vte many times without disabling anything.
Is your system using XT pax from when you first installed it or did you migrate from PT pax.
If it's the latter than you will have programs that were emerged before the switch and that therefore don't have paxmarks. There is migrate-pax from the elfix package that in theory should be able to fix such issues.
You could also look in the logs and see what binary gets killed and check if PT flags and XT pax are consistent (e.g. with paxctl-ng -v <binary>).

so i think i finally figured out what you're seeing and this is a sort of design decision vs. logic bug that cannot be resolved that easily (as in, without consequences).

what happens fundamentally is that in pax_parse_xattr_pax any invalid return value from pax_getxattr (which is basically a wrapper around the filesystem's getxattr method) is treated as 'failure' in that no further processing is done on the non-retrieved xattr and therefore the xattr specific softmode/hardmode functions don't get called and the code eventually falls back to a default state where everything is enforced (regardless of softmode).

now this can be 'fixed' if i treated such getxattr failures as returning an empty xattr value for user.pax.flags and ran the rest of the xattr handling logic that would correctly set the PaX flags for softmode as well. however this also means that any other reason (of not being able to get the xattr) would result in the same treatment which is why the design dilemma emerges . as a comparison, the lack of PT_PAX_FLAGS results in the same behaviour as a missing xattr is treated now, so in that respect the behaviour is consistent. however PT_PAX_FLAGS was also designed to require that header present in the ELF files, whereas user.pax.flags xattr isn't required, defaults are (or rather, should be) used when it's not present on a file.

after some code reading it seems that i can rely on -ENODATA (-ENOATTR) to separate out the interesting case for me, so let's see if the next patch works better.