Differences between revisions 33 and 34
Revision 33 as of 2016-01-06 01:11:30
Size: 6834
Editor: DrWhax
Comment:
Revision 34 as of 2016-01-08 22:00:04
Size: 6714
Editor: ckujau
Comment: deb.mempo.org is no more...?
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
=== You can use Mempo kernel === === Mempo kernel ===
Line 37: Line 37:
There is a Debian Repository with ready to use grsecurity kernels being maintained by '''Mempo project'''. There was a Debian repository with ready to use grsecurity kernels being maintained by '''Mempo project'''.
Line 39: Line 39:
The work is in progress, but it is fully usable as of 2014.06 just follow the install instructions carefully; The project appears to be dormant but it was fully usable as of 06/2014.
Line 43: Line 43:
 * '''http://deb.mempo.org''' - the '''install instructions'''
 * http://mempo.org - general description of the entire broad Mempo project: hardened debian-based system
 * [[http://web.archive.org/web/20150219015347/http://deb.mempo.org/|deb.mempo.org]] (archive.org)

Translation(s): none


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: comparsion) 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

The official wiki of grsecurity: https://en.wikibooks.org/wiki/Grsecurity

Wikipedia: grsecurity

Using in Debian

grsecurity Packages

There are official Debian packages for the grsecurity kernel patches available: https://packages.debian.org/linux-patch-grsecurity2.

Note that these are not configurable as to security/performance and overhead as usually done with manually building grsec/PaX support for the Linux kernel.

Now in unstable Debian

If you add the unstable repo's to your apt sources.list. You can install Grsecurity's testing kernel using: apt-get install -t unstable linux-grsec.

There are other alternatives available, although, sometimes, less up-to-date then the Debian package.

Maintaining PaX flags

Subgraph wrote a nice tool to set, maintain and retain PaX flags for binaries. At the time of writing, there wasn't a Debian package available. https://github.com/subgraph/paxrat

Mempo kernel

There was a Debian repository with ready to use grsecurity kernels being maintained by Mempo project.

The project appears to be dormant but it was fully usable as of 06/2014.

This implements SameKernel (also a script created by Mempo) - your kernel is compiled to identical .deb when you build from sources, so you can cross verify with friends to confirm there is no backdoor added at compilation.

You can build the kernel yourself

http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package

You can use Corsac repository

Corsac, the security researcher working with Debian, provides grsecurity patched kernels for Debian in own repository http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/

This 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.

They are also in form of correct Debian repository (as of 2014-03-26 Mempo is not, but it plans to provide this soon).

Compatibility

Grsecurity has many options

  • toggable in kernel configuration (compile-time)
  • then some more settings can be set on run or boot
  • finally RBAC profile can be loaded

Depending on thoes settings you get various speed and compatibility. See ?Mempo#variants for the options provided by ?Mempo in their kernel.

In general following things could be blocked:

  • you need to run the script grsecurity/setfattr or programs using JIT, especially java, python and javascript using - implying also firefox (iceweasel), thunderbird etc will be blocked by PAX

  • binary drivers, including video drivers like propertiary 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-addess thing? (possibly tunable in runtime?)
  • 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

Performance

Comparing performance

2014-03-03

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 syscals slower).

In conclusion, in general usage expect 70-100% performance, while benefiting from the very high security of kernel and protection for applications.

Performance old version (could be less correct)

Time of Nano compilation (CPU and disk usage). Debian with default kernel and kernel with Grsecurity (Mempo).

https://p.suchdig.com/p/cwm-Performance_compare_pdf-perf_comp.pdf

Conclusions: with 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 ?near future we plant to release other settings, allowing user to choose a bit lower security while gaining performance, or even higher one for most paranoid setup.