Mandatory access control for GNU/Linux
Why MAC
With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Under MAC (and unlike DAC), users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users.
Security-Enhanced Linux (SELinux) is an implementation of MAC in the Linux kernel, checking for allowed operations after standard discretionary access controls (DAC) are checked. SELinux can enforce a user-customizable security policy on running processes and their actions, including attempts to access file system objects. Enabled by default in Red Hat Enterprise Linux, SELinux limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services, such as the hypervisor. There are three options built-in Linux kernel source code, SELinux, Tomoyo, and Apparmor. Theoretically, MAC cannot be bypassed by applications unlike the policy based DAC. But the most secured MAC comes from Grsecurity/Pax.
What can Grsecurity/Pax do
Grsecurity is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats through intelligent access control, memory corruption-based exploit prevention, and a host of other system hardening that generally require no configuration. It has been actively developed and maintained for the past 13 years. Commercial support for Grsecurity is available through Open Source Security, Inc.
Here are the security features from Grsecurity.
Bounds checks on kernel copies to/from userland
Prevents direct userland access by kernel
Prevents kernel stack overflows on 64-bit architectures
Hardened userland memory permissions
Random padding between thread stacks
Hardened BPF JIT against spray attacks
Automatically responds to exploit brute forcing
Chroot hardening
Prevents users from tricking Apache into accessing other users’ files
Eliminates side-channel attacks against admin terminals
Provides Trusted Path Execution
Hide other users’ processes for unprivileged users
Mandatory access control
Automatic full system policy learning
Human-readable policies and logs
Intuitive design
Automated policy analysis
Unconventional features
Stackable with LSM
What Grsecurity can do
Grsecurity has Grsecurity and Pax two modules, and offering:
Access control
When Grsecurity is enabled, all the user space applications are running under Grsecurity MAC, the policy is whitelist, and even the root privilege is controlled by MAC. For instance, when default Grsecurity policy enabled, root user cannot use ping.
Such as ‘ping 10.0.0.1’ is not permitted by default because there are no explicit rules to permit ‘ping’.
Taking the OpenSSL heartbleed vulnerability as an example, malicious application, or attackers are trying access the memory stack out of its own boundary, Grsecurity will block it by default.
