grsecurity is a set of patches for the Linux kernel with an emphasis on enhancing security.
protects kernel. Regular Debian kernels, even with SE Linux are open to many forms of kernel bugs until given bug is patched. While grsecurity uses various hardening strategies to stop even unknown yet (0 day) bugs - additional checks, randomization of layout (more then regular kernel does), protecting memory from write access.
provides RBAC protection similar to SE Linux (TODO: comparison) This needs to be configured in user-space to have effect.
protects applications from unknown bugs by changing their memory to RO (read-or-execute), randomizing their layout and providing other help from kernel side to them
fixes security of chroot turning it into real, unescapable chroot-jail
various misc security upgrades
Usage in Debian
There are official Debian packages for grsecurity available:
linux-image-grsec: pre-built images, up to date, only in unstable
linux-patch-grsecurity2: *extremely outdated*, patches only, you have to build images yourself
Note that these are not configurable as to security/performance and overhead, as it's usually done with manually building grsec/PaX support for the Linux kernel.
Maintaining PaX flags
Subgraph wrote a nice toolset called paxrat to maintain and retain PaX flags for binaries. At the time of writing, there wasn't a Debian package available.
Corsac, a security researcher working with Debian, provides grsecurity patched kernels for Debian in a repository.
These patches seem to be superior in terms of being done the "right way" - though this is important mostly for development of the patched kernel, not so much for resulting kernel image to be used on system.
Grsecurity has many options:
- togglable in kernel configuration (compile-time)
- then some more settings can be set on run or boot
- finally RBAC profile can be loaded
In general following things could be blocked:
- binary drivers, including video drivers like proprietary NVidia or Radeon in general will probably not work on higher levels, but they are security risk
almost all video drivers even the open-ones would be blocked by good security, which is meant mostly for headless (or text) servers. In future a patched Xorg program would allow them to run probably (it's about blocking kmem and ioport access - which blocks important route of attacking kernel by modifying raw memory)
- possibly wine would be blocked by the no-0-address thing? (possibly tunable in runtime?)
When mounting a remote file system using sshfs: fuse: device not found, try 'modprobe fuse' first. You need to manually load fuse module as a root: # modprobe fuse
- Same as above for other auto-loaded modules, you might need to load them by hand. (Other solutions perhaps exist too)
Things that work:
- open source video drivers (at least on some levels)
- other open source and built-in drivers - HOW EVER you might need to modprobe load the modules manually for some things
- KVM visualization is known to work (as the host)
- KVM visualization as the guest also works (using this kernels on a system in KVM VM)
- all other normal operation for Desktop and Server
- members of Mempo team along with friends used grsecurity on their primary Desktops for year+ without trouble
Test on Wheezy, amd64, no RBAC, Mempo 0.1.28 (kernel 3.2.55) on good variant (high security - almost all grsecurity options).
- CPU only - 100% (povray rendering of raytraced image, on a desktop) - the same (actually seemed a bit better, possibly to measurement errors, or our kernel giving less priority to background task distractions).
- CPU/sys/disk - 70% (compilation of povray c/c++ from it's source code, on a desktop)
- disk only - not tested (we expect the transfers to be same but syscalls slower).
In conclusion, in general usage expect 70-100% performance, while benefiting from the very high security of kernel and protection for applications.
Time of Nano compilation (CPU and disk usage). Debian with default kernel and kernel with Grsecurity (Mempo).
Conclusions: with a Grsecurity hardened kernel on security setting -good, general tasks like compilation seem to be 30-40% slower, disk usage speed seems to be the same and compilation time requires to be benchmarked more.
In the near future we plan to release other settings, allowing the user to choose a bit lower security while gaining performance, or even higher one for the most paranoid setup.