https://wiki.archlinux.org/api.php?action=feedcontributions&user=TheReverend403&feedformat=atomArchWiki - User contributions [en]2024-03-28T14:05:54ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Grsecurity&diff=310430Grsecurity2014-04-14T18:44:53Z<p>TheReverend403: Display how to enable gradm after learning the policy.</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Security]]<br />
From [http://grsecurity.net/ Grsecurity homepage]:<br />
<br />
:''Unlike other expensive security "solutions" that pretend to achieve security through known-vulnerability patching, signature-based detection, or other reactive methods, grsecurity provides real proactive security. The only solution that hardens both your applications and operating system, grsecurity is essential for public-facing servers and shared-hosting environments.''<br />
<br />
The grsecurity project provides patches to the Linux kernel which enhance security further than many other solutions. The main advantage is a "learning mode" designed to configure a tight Mandatory Access Control almost effortlessly. Comparable security implementations include SELinux and Apparmor. It is up to the user to decide which one is appropriate.<br />
<br />
In order to utilize grsecurity most effectively, it is understood that the reader has a working knowledge of computer security in general.<br />
<br />
== Build options ==<br />
<br />
There are three ways you can install a grsecurity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to use the binary grsecurity kernel repository. If you have the time, build the AUR package yourself for added security.<br />
<br />
{{note|Any way you choose to install the grsecurity kernel you will need to also install {{AUR|gradm}}, {{AUR|paxctl}}, and {{AUR|linux-pax-flags}}}}<br />
<br />
=== Install binary kernel packages ===<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
If you rely on specific hooks, like {{AUR|catalyst-hook}}, you have to install the headers first with {{ic|pacman -Sy linux-grsec-headers}}.<br />
<br />
After configuration of grsecurity sysctl options, set {{ic|kernel.grsecurity.grsec_lock &#61; 1}} in {{ic|/etc/sysctl.d/10-grsecurity.conf}}, so no hardening option can be deactivated later (even by root).<br />
<br />
=== Build kernel from AUR ===<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
The AUR has all the utilities and kernel packages you need to run a hardened Arch Linux system. There is even a script called {{AUR|linux-pax-flags}} which will make using PaX as painless as possible by setting all the PaX flags automatically.<br />
<br />
==== Download files ====<br />
<br />
Download the packages<br />
{{AUR|linux-grsec}}<br />
Or<br />
{{AUR|linux-grsec-lts}}<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
==== Verify the GPG signatures ====<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
==== Setup build environment ====<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
==== Build the kernel package ====<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
==== Make a backup ====<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
==== Install PaX and RBAC utilities ====<br />
<br />
The AUR has three utilities you will need to install. They are {{AUR|paxctl}}, {{AUR|gradm}}, and {{AUR|linux-pax-flags}}.<br />
<br />
==== Set PaX Flags ====<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
==== Install hardened kernel ====<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
=== Build kernel without the AUR ===<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you cannot find a certain option, there is always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== RBAC ==<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
=== Configuring the kernel ===<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
=== Working with gradm ===<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
=== Generating a policy ===<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -D<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
# gradm -E<br />
<br />
=== Tweaking your policy ===<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
<br />
== PaX ==<br />
<br />
==== Fighting the exploitation of software bugs ====<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and should not contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
==== PaX kernel configuration ====<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration did not activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Other features ==<br />
<br />
=== Filesystem protection ===<br />
<br />
==== Fighting chroot and filesystem abuse ====<br />
<br />
Grsecurity includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on {{ic|/proc}} usage, chrooting, linking, etc.<br />
<br />
===== Kernel configuration =====<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
===== Triggering the Security Mechanism =====<br />
<br />
When you are using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical {{ic|/etc/sysctl.d/10-grsecurity.conf}}.<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
=== Kernel auditing ===<br />
<br />
==== Extend your system's logging facilities ====<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
==== The various Kernel Audit Settings ====<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
==== Process restrictions ====<br />
<br />
===== Executable protection =====<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
===== Network protection =====<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access altogether.<br />
<br />
===== Kernel settings =====<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
== Using linux-pax-flags AUR package ==<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on its man page.<br />
<br />
== Tips and tricks ==<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, because of this none of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as {{Pkg|nmon}} or {{Pkg|nload}} and run them as root, or as a user in the proc-trusted group.</div>TheReverend403https://wiki.archlinux.org/index.php?title=Grsecurity&diff=310429Grsecurity2014-04-14T18:43:21Z<p>TheReverend403: gradm has to be re-disabled before processing learned rules otherwise it claims the learning.log doesn't exist.</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Security]]<br />
From [http://grsecurity.net/ Grsecurity homepage]:<br />
<br />
:''Unlike other expensive security "solutions" that pretend to achieve security through known-vulnerability patching, signature-based detection, or other reactive methods, grsecurity provides real proactive security. The only solution that hardens both your applications and operating system, grsecurity is essential for public-facing servers and shared-hosting environments.''<br />
<br />
The grsecurity project provides patches to the Linux kernel which enhance security further than many other solutions. The main advantage is a "learning mode" designed to configure a tight Mandatory Access Control almost effortlessly. Comparable security implementations include SELinux and Apparmor. It is up to the user to decide which one is appropriate.<br />
<br />
In order to utilize grsecurity most effectively, it is understood that the reader has a working knowledge of computer security in general.<br />
<br />
== Build options ==<br />
<br />
There are three ways you can install a grsecurity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to use the binary grsecurity kernel repository. If you have the time, build the AUR package yourself for added security.<br />
<br />
{{note|Any way you choose to install the grsecurity kernel you will need to also install {{AUR|gradm}}, {{AUR|paxctl}}, and {{AUR|linux-pax-flags}}}}<br />
<br />
=== Install binary kernel packages ===<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
If you rely on specific hooks, like {{AUR|catalyst-hook}}, you have to install the headers first with {{ic|pacman -Sy linux-grsec-headers}}.<br />
<br />
After configuration of grsecurity sysctl options, set {{ic|kernel.grsecurity.grsec_lock &#61; 1}} in {{ic|/etc/sysctl.d/10-grsecurity.conf}}, so no hardening option can be deactivated later (even by root).<br />
<br />
=== Build kernel from AUR ===<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
The AUR has all the utilities and kernel packages you need to run a hardened Arch Linux system. There is even a script called {{AUR|linux-pax-flags}} which will make using PaX as painless as possible by setting all the PaX flags automatically.<br />
<br />
==== Download files ====<br />
<br />
Download the packages<br />
{{AUR|linux-grsec}}<br />
Or<br />
{{AUR|linux-grsec-lts}}<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
==== Verify the GPG signatures ====<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
==== Setup build environment ====<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
==== Build the kernel package ====<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
==== Make a backup ====<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
==== Install PaX and RBAC utilities ====<br />
<br />
The AUR has three utilities you will need to install. They are {{AUR|paxctl}}, {{AUR|gradm}}, and {{AUR|linux-pax-flags}}.<br />
<br />
==== Set PaX Flags ====<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
==== Install hardened kernel ====<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
=== Build kernel without the AUR ===<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you cannot find a certain option, there is always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== RBAC ==<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
=== Configuring the kernel ===<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
=== Working with gradm ===<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
=== Generating a policy ===<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -D<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
=== Tweaking your policy ===<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
<br />
== PaX ==<br />
<br />
==== Fighting the exploitation of software bugs ====<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and should not contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
==== PaX kernel configuration ====<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration did not activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Other features ==<br />
<br />
=== Filesystem protection ===<br />
<br />
==== Fighting chroot and filesystem abuse ====<br />
<br />
Grsecurity includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on {{ic|/proc}} usage, chrooting, linking, etc.<br />
<br />
===== Kernel configuration =====<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
===== Triggering the Security Mechanism =====<br />
<br />
When you are using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical {{ic|/etc/sysctl.d/10-grsecurity.conf}}.<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
=== Kernel auditing ===<br />
<br />
==== Extend your system's logging facilities ====<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
==== The various Kernel Audit Settings ====<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
==== Process restrictions ====<br />
<br />
===== Executable protection =====<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
===== Network protection =====<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access altogether.<br />
<br />
===== Kernel settings =====<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
== Using linux-pax-flags AUR package ==<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on its man page.<br />
<br />
== Tips and tricks ==<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, because of this none of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as {{Pkg|nmon}} or {{Pkg|nload}} and run them as root, or as a user in the proc-trusted group.</div>TheReverend403https://wiki.archlinux.org/index.php?title=Java&diff=308550Java2014-04-05T14:25:06Z<p>TheReverend403: Updated JDK/JRE implementations because JDK/JRE is now Java 8</p>
<hr />
<div>[[Category:Programming language]]<br />
[[cs:Java]]<br />
[[de:Java]]<br />
[[es:Java]]<br />
[[fr:Java]]<br />
[[it:Java]]<br />
[[ja:Java]]<br />
[[pt:Java]]<br />
[[ru:Java]]<br />
[[tr:Java]]<br />
{{Related articles start}}<br />
{{Related|Java Package Guidelines}}<br />
{{Related articles end}}<br />
"''Java is a programming language originally developed by Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java applications are typically compiled to bytecode that can run on any Java virtual machine (JVM) regardless of computer architecture.''" — [[Wikipedia:Java (programming language)|Wikipedia article]]<br />
<br />
== Installation ==<br />
The only supported JVM implementation in Arch Linux is the open source [http://openjdk.java.net/ OpenJDK]. It is nearly perfect, and it should not be necessary to install Oracle's proprietary version of Java. If you want to install Oracle Java alongside OpenJDK, see [[#JDK-compat]].<br />
<br />
{{Note|After installation, the Java environment will need recognized by the shell ({{Ic|$PATH}} variable and {{Ic|$JAVA_HOME}}). This can be done from the command line by sourcing {{Ic|/etc/profile}}, and for Desktop Environments it is likely a logout/login will be necessary.}}<br />
<br />
=== OpenJDK ===<br />
The OpenJDK Java runtime environment (''JRE'') can be installed with the package {{Pkg|jre7-openjdk}}, available in the [[official repositories]]. There is also a Java development kit (''JDK'') available with the package {{Pkg|jdk7-openjdk}}. Sources are available with the package {{Pkg|openjdk7-src}}.<br />
<br />
If you want Java functionality in browsers ([[Wikipedia:Java applet|Java applets]] and [[Wikipedia:Java Web Start|Java Web Start]]), install {{Pkg|icedtea-web-java7}}. For more details see [[Browser plugins#Java (IcedTea)]].<br />
<br />
==== Flagging packages as out-of-date ====<br />
*{{Pkg|jre7-openjdk}}, {{Pkg|jdk7-openjdk}} and {{Pkg|jre7-openjdk-headless}} should be flagged as out-of-date based on the [http://icedtea.wildebeest.org/download/source ''IcedTea'' version] (e.g. {{ic|2.4.3}}), rather than on their Oracle version (e.g. {{ic|u45}}).<br />
*{{Pkg|icedtea-web-java7}} should be flagged as out-of-date based on the [http://icedtea.wildebeest.org/download/source ''IcedTea Web'' version] (e.g. {{ic|1.4.1}}). This is independent of the ''IcedTea'' version.<br />
<br />
=== Oracle Java SE ===<br />
The Oracle implementations of JRE and JDK are available in the [[AUR]]: {{AUR|jre}} and {{AUR|jdk}}.<br />
<br />
==== Java SE 6/7 ====<br />
The [[AUR]] contains {{AUR|jre6}}/{{AUR|jre7}} and {{AUR|jdk6}}/{{AUR|jdk7}}, which are the Oracle implementations of Java SE 6 and Java SE 7.<br />
<br />
==== JDK-compat ====<br />
The Oracle JDK (6 and 7) can also be installed in parallel with another Java installation (for example OpenJDK). The packages can be found in the [[AUR]]: {{AUR|jdk6-compat}} and {{AUR|jdk7-compat}}.<br />
<br />
=== Oracle JRockit ===<br />
[http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html JRockit] is a JIT version of Java, provided by Oracle and available as {{AUR|jrockit}} from the [[AUR]].<br />
<br />
=== VMkit ===<br />
[http://vmkit.llvm.org/index.html VMkit] is an LLVM-based framework for JIT virtual machines. J3 is a JVM running on VMkit. The webpage can be found here: [http://vmkit.llvm.org/get_started.html vmkit]. J3 depends on the GNU classpath libraries, but may also work with the Apache class path libraries.<br />
<br />
=== Parrot VM ===<br />
[http://www.parrot.org/ Parrot] is a VM that offers experimental [http://trac.parrot.org/parrot/wiki/Languages support for Java] through two different methods: Either as a [http://code.google.com/p/parrot-jvm/ Java VM bytecode translator] or as a [https://github.com/chrisdolan/perk Java compiler targeting the Parrot VM]. {{Pkg|parrot}} is available in the [[official repositories]] and {{AUR|parrot-git}} in the [[AUR]].<br />
<br />
== Troubleshooting ==<br />
=== MySQL ===<br />
Due to the fact that the JDBC-drivers often use the port in the URL to establish a connection to the database, it is considered "remote" (i.e., MySQL does not listen to the port as per its default settings) despite the fact that they are possibly running on the same host, Thus, to use JDBC and MySQL you should enable remote access to MySQL, following instructions in [[MySQL#Enable remote access|MySQL article]].<br />
<br />
=== Java sound with PulseAudio ===<br />
{{Note|This procedure is likely to be relevant for previous version of Java (Java 6) only.}}<br />
<br />
By default, Java and [[PulseAudio]] do not get along very well with each other, but this is easy to fix using padsp.<br />
<br />
(These paths are correct for Sun's Java, you will need to change the paths for OpenJDK)<br />
<br />
First, rename the {{Ic|java}} binary to {{Ic|java.bin}}<br />
# mv /opt/java/jre/bin/java /opt/java/jre/bin/java.bin<br />
Then, create a new launcher script at {{Ic|/opt/java/jre/bin/java}}<br />
#!/bin/sh<br />
padsp /opt/java/jre/bin/java.bin "$@"<br />
Finally, make the launcher script executable<br />
# chmod +x /opt/java/jre/bin/java<br />
You will need to redo this process on each update of Java.<br />
<br />
You can also try replacing padsp with aoss, which can also fix it under standard ALSA as well as in Pulse, do what works best. I must warn everyone that these hacks sometimes work perfectly, but are sometimes very unstable as well.<br />
<br />
=== Impersonate another window manager ===<br />
You may use the {{pkg|wmname}} from [http://tools.suckless.org/wmname suckless.org] to make the JVM believe you are running a different window manager. This may solve a rendering issue of Java GUIs occurring in window managers like [[Awesome]] or [[Dwm]].<br />
$ wmname LG3D<br />
<br />
You must restart the application in question after issuing the wmname command.<br />
<br />
This works because the JVM contains a hard-coded list of known, non-re-parenting window managers. For maximum irony, some users prefer to impersonate {{ic|LG3D}}, the non-re-parenting window manager [https://en.wikipedia.org/wiki/Project_Looking_Glass written by Sun, in Java].<br />
<br />
=== Illegible fonts ===<br />
In addition to the suggestions mentioned below in [[#Better_font_rendering]], some fonts may still not be legible afterwards. If this is the case, there is a good chance Microsoft fonts are being used. Install {{AUR|ttf-ms-fonts}} from the [[AUR]].<br />
<br />
=== Missing dependencies ===<br />
If you encounter, often when installing from the AUR, a missing dependency of ''java-runtime'', you might need to install some form of jdk.<br />
<br />
== Tips and tricks ==<br />
{{Note|Suggestions in this section are applicable to all applications, using explicitly installed (external) Java runtime. Some applications are bundled with own (private) runtime or use own mechanics for GUI, font rendering, etc., so none of written below is guaranteed to work.}}<br />
<br />
Behavior of most Java applications can be controlled by supplying predefined variables to Java runtime. From [https://bbs.archlinux.org/viewtopic.php?id=72892 this forum post], a way to do it consists of adding the following line in your {{Ic|~/.bashrc}} (or {{Ic|/etc/profile.d/jre.sh}} to affect programs that are not run by sourcing {{Ic|~/.bashrc}}, e.g., launching a program from Gnome's Applications view):<br />
<br />
export _JAVA_OPTIONS="-D'''<option 1>''' -D'''<option 2>'''..."<br />
<br />
For example, to use system anti-aliased fonts and make swing use the GTK look and feel:<br />
<br />
export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel'<br />
<br />
=== Better font rendering ===<br />
Both closed source and open source implementations of Java are known to have improperly implemented anti-aliasing of fonts. This can be fixed with the following options: {{Ic|1=awt.useSystemAAFontSettings=on}}, {{Ic|1=swing.aatext=true}}<br />
<br />
=== GTK LookAndFeel ===<br />
If your Java programs look ugly, you may want to set up the default look and feel for the swing components: {{Ic|1=swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel}}.<br />
<br />
Some stubborn Java programs insist on using the cross platform Metal look and feel. In some of these cases you can force these apps to use the GTK look and feel by setting the following property:<br />
<br />
{{Ic|1=swing.crossplatformlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel}}.<br />
<br />
=== Symlinks change ===<br />
Typically, OpenJDK installation creates symlinks in {{Ic|/usr/bin}} for java, javac ... etc. If you want to change these symlinks to any other JDK (e.g. if you installed environment-compat packages of Oracle JDK), [https://github.com/d1x/linux-utils/blob/master/replace-java-symlinks.sh this] script might be handy for you.</div>TheReverend403