grsecurity

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

grsecurity
Developer(s)Brad Spengler (Spender), PaX Team (pipacs)
Repository Edit this at Wikidata
Operating systemLinux
PlatformLinux kernel
TypeSecurity
LicenseGPL v2
Websitegrsecurity.net

grsecurity is a set of patches for the Linux kernel which emphasize security enhancements.[1] The patches are typically used by computer systems which accept remote connections from untrusted locations, such as web servers and systems offering shell access to its users. Grsecurity provides a collection of security features to the Linux kernel, including address space protection, enhanced auditing and process control.

Grsecurity is produced by Open Source Security, Inc., headquartered in Pennsylvania,[2] and since April 2017 the patches are only available to their paying customers.[3]

Components[edit]

PaX[edit]

A major component bundled with grsecurity is PaX. Among other features, the patch flags data memory, the stack, for example, as non-executable and program memory as non-writable. The aim is to prevent memory from being overwritten, which can help to prevent many types of security vulnerabilities, such as buffer overflows. PaX also provides address space layout randomization (ASLR), which randomizes important memory addresses to reduce the probability of attacks that rely on easily predicted memory addresses.

Role-based access control[edit]

Another notable component of grsecurity is that it provides a full role-based access control (RBAC) system. RBAC is intended to restrict access to the system further than what is normally provided by Unix access control lists, with the aim of creating a fully least-privilege system, where users and processes have the absolute minimum privileges to work correctly and nothing more. This way, if the system is compromised, the ability of the attacker to damage or gain sensitive information on the system can be drastically reduced. RBAC works through a collection of roles. Each role can have individual restrictions on what it can or cannot do, and these roles and restrictions form an access policy which can be amended as needed.

A list of RBAC features:

  • Domain support for users and groups
  • Role transition tables
  • IP-based roles
  • Non-root access to special roles
  • Special roles that require no authentication
  • Nested subjects
  • Support for variables in the configuration
  • And, or, and difference set operations on variables in configuration
  • Object mode that controls the creation of setuid and setgid files
  • Create and delete object modes
  • Kernel interpretation of inheritance
  • Real-time regular expression resolution
  • Ability to deny ptraces to specific processes
  • User and group transition checking and enforcement on an inclusive or exclusive basis
  • /dev/grsec entry for kernel authentication and learning logs
  • Next-generation code that produces least-privilege policies for the entire system with no configuration
  • Policy statistics for gradm
  • Inheritance-based learning
  • Learning configuration file that allows the administrator to enable inheritance-based learning or disable learning on specific paths
  • Full path names for offending process and parent process
  • RBAC status function for gradm
  • /proc/<pid>/ipaddr gives the remote address of the person who started a given process
  • Secure policy enforcement
  • Supports read, write, append, execute, view, and read-only ptrace object permissions
  • Supports hide, protect, and override subject flags
  • Supports the PaX flags
  • Shared memory protection feature
  • Integrated local attack response on all alerts
  • Subject flag that ensures a process can never execute trojaned code
  • Full-featured, fine-grained auditing
  • Resource, socket, and capability support
  • Protection against exploit bruteforcing
  • /proc/pid filedescriptor/memory protection
  • Rules can be placed on non-existent files/processes
  • Policy regeneration on subjects and objects
  • Configurable log suppression
  • Configurable process accounting
  • Human-readable configuration
  • Not filesystem or architecture dependent
  • Scales well: supports as many policies as memory can handle with the same performance hit
  • No run-time memory allocation
  • SMP safe
  • O(1) time efficiency for most operations
  • Include directive for specifying additional policies
  • Enable, disable, reload capabilities
  • Option to hide kernel processes

Chroot restrictions[edit]

grsecurity restricts chroot in a variety of ways to prevent various vulnerabilities and privilege escalation attacks, as well as to add additional checks:

  • No attaching shared memory outside chroot
  • No kill, ptrace (architecture-independent), capget, setpgid, getpgid and getsid outside chroot
  • No sending of signals by fcntl outside chroot
  • No viewing of any process outside chroot, even if /proc is mounted
  • No mounting or remounting
  • No pivot_root
  • No double chroot
  • No fchdir out of chroot
  • Enforced chdir("/") upon chroot
  • No (f)chmod +s
  • No mknod
  • No sysctl writes
  • No raising of scheduler priority
  • No connecting to abstract unix domain sockets outside chroot
  • Removal of harmful privileges via cap

Miscellaneous features[edit]

Among other things, it can be configured to audit a specific group of users, mounting/unmounting of devices, changes to the system time and date, and chdir logging. Some of the other audit types allow the administrator to also log denied resource attempts, failed fork attempts, IPC creation and removal, and exec logging together with its arguments.

Trusted path execution is another optional feature that can be used to prevent users from executing binaries not owned by the root user, or world-writable binaries. This is useful to prevent users from executing their own malicious binaries or accidentally executing world-writable system binaries that could have been modified by a malicious user.

grsecurity also hardens the way chroot "jails" work. A chroot jail can be used to isolate a particular process from the rest of the system, which can be used to minimise the potential for damage should the service be compromised. There are ways to "break out" of a chroot jail, which grsecurity attempts to prevent.

There are also other features that increase security and prevent users from gaining unnecessary knowledge about the system, such as restricting the dmesg and netstat commands to the root user.[4]

List of additional features and security improvements:

  • /proc restrictions that do not leak information about process owners
  • Symlink/hardlink restrictions to prevent /tmp races
  • FIFO restrictions
  • dmesg restriction
  • Enhanced implementation of trusted path execution
  • GID-based socket restrictions
  • Nearly all options are sysctl-tunable, with a locking mechanism
  • All alerts and audits support a feature that logs the IP address of the attacker with the log
  • Stream connections across Unix domain sockets carry the attacker's IP address with them (on 2.4 only)
  • Detection of local connections: copies attacker's IP address to the other task
  • Automatic deterrence of exploit brute-forcing
  • Low, medium, high, and custom security levels
  • Tunable flood-time and burst for logging

Inclusion in the mainline Linux kernel[edit]

The grsecurity patches have never been submitted for inclusion in the mainline Linux kernel, for the following reasons:[5][6][3]

  • Breaking up and submitting parts of the patches doesn't in the end reduce Grsecurity developers' workload on maintaining the rest.
  • Many features are designed to be build up on or augment each other, and thus are not intended to be submitted and used separately.
  • Some of the features are never going to be accepted, based on what Linus Torvalds himself thinks[7] about their implementation details and technological foundations per se.

Speculations on GPLv2 violation and copyright infringement[edit]

After access to the grsecurity stable patches was restricted, Bruce Perens speculated in a blog post that using the patches obtained under OSS, Inc.'s Stable Patch Access Agreement,[8] which, according to Perens, "adds a term to the GPL prohibiting distribution or creating a penalty for distribution", may expose clients to legal risk, such as copyright infringement. Brad Spengler of Open Source Security, Inc. sued for defamation;[9][10] but lost in the district court, and was directed to pay Bruce Perens and his legal team almost $260,000.[11] Presently, the case is in the process of appeal.[12]

See also[edit]

References[edit]

  1. ^ "Grsecurity Features".
  2. ^ "Open Source Security Inc. Announces World-First Fully CFI-Hardened OS Kernel". PRWeb. Retrieved 2017-07-05.
  3. ^ a b Corbet, Jonathan. "Grsecurity goes private". LWN.net. Retrieved 27 January 2019.
  4. ^ "grsecurity". grsecurity.net. Retrieved 2010-08-12.
  5. ^ Edge, Jake (7 January 2009). "The future for grsecurity". Retrieved 28 January 2019.
  6. ^ PaXTeam (15 January 2009). "The future for grsecurity". LWN.net. Retrieved 10 February 2019.
  7. ^ Torvalds, Linus (3 January 2009). "Re: Grsecurity is about to be discontinued, unless..." LKML.org. Retrieved 10 February 2019.
  8. ^ "EXHIBIT B: Stable Patch Access Agreement" (PDF). p. 5. Retrieved 10 February 2019.
  9. ^ "Complaint For: 1. DEFAMATION PER SE 2. DEFAMATION PER QUOD 3. FALSE LIGHT 4. TORTIOUS INTERFERENCE WITH PROSPECTIVE ADVANTAGE ; DEMAND FOR JURY TRIAL" (PDF). Retrieved 10 February 2019.
  10. ^ "Opposition to Defendant Bruce Perens' Motion to Dismiss pursuant to Fed. R. Civ. P. 12(b)(6) And Special Motion to Strike pursuant to CA. Code of Civ. P. § 425.16. and Bradley Spengler's Decl. In Support to Opposition to Perens' Motion to Dismiss and Special Motion to Strike" (PDF). Retrieved 10 February 2019.
  11. ^ Claburn, Thomas (11 Jun 2018). "Open Source Security hit with bill for defamation claim". The Register. Retrieved 28 January 2019.
  12. ^ Claburn, Thomas (19 January 2018). "Linux's Grsecurity dev team takes blog 'libel' fight to higher court". The Register. Retrieved 10 February 2019.

External links[edit]