- 1 ATI Catalyst (fglrx) graphics driver
- 2 cPanel jailshell
- 3 Firefox (or Iceweasel in Debian)
- 4 Google Chrome 15.0.874.106
- 5 Grub
- 6 GUFW/UFW firewalls or Update Manager
- 7 IOQuake3
- 8 ISC DHCP Server
- 9 Java
- 10 Nagios
- 11 Node.js
- 12 Openoffice.org
- 13 libreoffice.org
- 14 PHP and other applications that set their own resource limits
- 15 X.org
This page lists applications that need specific settings to work with grsecurity and PaX. If you wish to add an application to the list, you are most welcome to do so. Please keep the list in alphabetical order and remember to update the table of contents on the front page.
ATI Catalyst (fglrx) graphics driver
When using Xorg and the proprietary ATI Catalyst graphics driver, CONFIG_PAX_USERCOPY must not be set as PAX_USERCOPY prevents a real overflow from occurring in the ATI driver that is still unfixed. This is in addition to what's shown in the section on Xorg below.
As of 11.8, CONFIG_PAX_MEMORY_UDEREF must also be disabled.
Because cPanel's jailshell needs to mount filesystems (including bind mounts) after chrooting, both chroot_caps (due to needing CAP_SYS_ADMIN) and chroot_deny_mount will need to be disabled. To do this, either disable the respective options in your kernel configuration (CONFIG_GRKERNSEC_CHROOT_CAPS and CONFIG_GRKERNSEC_CHROOT_MOUNT) or disable them in an init script if GRKERNSEC_SYSCTL is enabled. Use the following commands:
echo 0 > /proc/sys/kernel/grsecurity/chroot_caps echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
We will be working with cPanel developers to see if the need for this workaround can be avoided in future jailshell versions.
Firefox (or Iceweasel in Debian)
Mozilla Firefox and possibly all, if not some(?) of, the lib.so files in the folder (/usr/lib/firefox) with the Firefox binary (called /usr/lib/firefox/firefox) need mprotect disabled for flash to function. Without the Firefox binary having disabled mprotect Firefox will enter an infinite loop at startup or take minutes to load. Without the lib.so files having mprotect disabled any page encountered with Flash will surely run an infinite loop and the Firefox process will have to be killed.
Firefox >= 3.5 may need RANDMMAP to be disabled (), if not it will enter in an infinite loop during startup. To disable, execute paxctl -r /firefox_binary. Usually the binary is somewhere in /usr/lib64/*firefox*. See http://bugs.gentoo.org/show_bug.cgi?id=278698 for more details. As of at least Firefox 13 on Ubuntu-based distros you can enable RANDMMAP.
Google Chrome 15.0.874.106
On Google Chrome:
$ paxctl -v /opt/google/chrome/chrome PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <email@example.com> - PaX flags: P----m-x-eR- [/opt/google/chrome/chrome] PAGEEXEC is enabled MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled RANDMMAP is enabled $ paxctl -v /opt/google/chrome/nacl_helper PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <firstname.lastname@example.org> - PaX flags: -p---m-x-e-- [/opt/google/chrome/nacl_helper] PAGEEXEC is disabled MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled $ paxctl -v /opt/google/chrome/chrome-sandbox PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <email@example.com> - PaX flags: -----m-x-e-- [/opt/google/chrome/chrome-sandbox] MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled
These PaX flags work well on my system with flash. Chrome's nacl does throw this however:
[1:1:14105440733:ERROR:nacl_fork_delegate_linux.cc(78)] Bad NaCl helper startup ack (0 bytes)
Grub uses nested functions and thus needs either PAX_EMUTRAMP enabled in the kernel and EMUTRAMP enabled on affected binaries, or if PAX_EMUTRAMP is not enabled in the kernel, needs MPROTECT disabled on affected binaries. Depending on the version of grub in use, some of the following files may not exist, but you should mark all those that exist. To add EMUTRAMP, use the '-CE' argument to paxctl. To remove MPROTECT, use '-Cm'.
/usr/bin/grub-script-check /usr/sbin/grub-probe /usr/sbin/grub-mkdevicemap
GUFW/UFW firewalls or Update Manager
GUFW is an optional graphical application interface for the Ubuntu firewall (UFW), both of which use Python. Update Manager is a Gnome application for updating packages that also depends on Python. Really, any application that uses Python try enabling EMUTRAMP for the version of Python that is the dependency of your affected program (GUFW or Update Manager). (Example: # paxctl -E /usr/bin/Python2.7).
Ioquake3 requires disabling mprotect restrictions to run correctly.
ISC DHCP Server
NOTE: grsecurity patches released as of May 4th, 2014 do not require the below modifications
On some systems, after upgrading to a grsecurity-enabled kernel with GRKERNSEC_PROC_USERGROUP enabled, the kernel log may be spammed with:
init: isc-dhcp-server main process ended, respawning init: isc-dhcp-server main process (pid) terminated with status 1
This may be due to unprivileged users not having access to /proc/net/dev as this dhcpd requires. You can confirm by running dhcpd -f from the command-line, which should display the following error:
Error opening '/proc/net/dev' to list interfaces
To fix this, grep your kernel config for CONFIG_GRKERNSEC_PROC_GID, then add a group for that gid to /etc/group if it doesn't already exist. Then add dhcpd to that group. The added line will look similar to:
As the DHCP server is continually attempting to respawn, upon making this change you should find it running properly.
With problems with an epoll stack trace lookup . Also there is a problem with just-in-time compilation. Disable mprotect for /usr/lib/jvm/java-6-sun-184.108.40.206/jre/bin/java and /usr/lib/jvm/java-6-sun-220.127.116.11/jre/bin/javaws.
Nagios needs to be able to view all processes on the system in order to accurately portray service status and performance statistics. It must therefore be run with the group of the CONFIG_GRKERNSEC_PROC_GID you configured, or as set with the grsec_proc_gid kernel command-line option.
Node.js needs to execute arbitrary code at runtime. To permit this, mprotect needs to be disabled. On most systems, this can be accomplished with the command:
paxctl -Cm /usr/bin/nodejs
Note: For certain apps like electron, you will need to disable mprotect for both the electron and nodejs executables
the same as openoffice.org, but libreoffice.org need to have unrestricted mprotect for:
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java to work if you use libreoffice-base: Database.
PHP and other applications that set their own resource limits
While Apache/PHP run very well with a grsec/PaX enabled kernel, you could feel like there are possible memory leaks or strange OOM (out of memory) errors with PHP using a PaX enabled kernel with the SEGMEXEC flag enabled. There's no memory leak, and the OOM errors are normal, particularly if you didn't set high enough resource limits.
Concerning "abnormal" memory usage with PHP and SEGMEXEC flag enabled, see spender's answers on http://bugs.php.net/bug.php?id=49501 comments:
"Due to VMA mirroring, the SEGMEXEC option causes accounted vm usage to double. So you weren't experiencing a memory leak -- you were just being accounted for twice as much memory as you thought you were using. The solution would be to double the resource limit or, if your system is NX-capable and PAE is enabled, use PAGEEXEC."
X.org might need some specific kernel settings during configuration (depending on the hardware and the drivers used X won't run with non-executable pages (PAX_NOEXEC)). The problem manifested especially in XFree4. Although, recent versions of X.org are known to work with non-executable pages enabled. If you run into problems with X watch your non-executeble settings.
Some users experience mouse freezes when the system load is high. Typically the mouse pointer is reset, but stays in the upper left corner of the screen. This behaviour was found to occur with certain pre-emption settings . It seems to be an interaction between forced-preemption and KERNEXEC. You should be able to re-enable KERNEXEC as long as you disable preemption or use voluntary preemption.
According to the Pax-Team KERNEXEC should work as is, since the changes should be only basic functions like open/close functions. If you should experience problems switch to voluntary or none pre-emption.