17 ms·

The status of Linux kernel hardening

214 points by cheiVia0 10y ago

cyphar 10y ago
Prepare for the lovely blog post from the grsecurity author who is going to proclaim how he is so much smarter than everyone else, and that upstream Linux doesn't know what they're doing. /sigh
- nwmcsween 10y ago
  grsec will sadly slowly become irrelevant, they could have worked with mainline but instead acted like little spoiled children.
  - micaksica 10y ago
    I disagree with this statement. grsec has been a proving ground for a lot of hardening technologies throughout the years, many of which are just starting to make it upstream through the Linux kernel political process. As long as the team that works on the grsecurity patchsets continues to innovate, it will not become irrelevant; instead, it will continue to be a testbed for things mainline will pick up and re-implement at their discretion.
    - nwmcsween 10y ago
      You seem to think grsec isn't in Linux due to the politics of submitting patches, grsec hasn't submitted piecemeal patches and their attitude is to derail conversations into name-calling. I recommend reading the comments in: http://lwn.net/Articles/663474/ http://lwn.net/Articles/663474/ or really anything where grsec team interacts with people. You can be the most intelligent human alive but if you cannot interact with people in a productive way it doesn't matter.
- voidz 10y ago
  What an non-constructive, cynical, depressing response. Grsecurity is a good product, components have been added to the kernel without proper attribution, and although Brad can admittedly add drama, how is this different from the drama your post adds? Pot, meet kettle.
totalZero 10y ago
I feel like such a moron when I read stuff like this, because I don't know what half the acronyms and technologies even are.
- NetOpWibby 10y ago
  Lmao, same.
- micaksica 10y ago
  KASLR: Kernel Address Space Layout Randomization. See https://en.wikipedia.org/wiki/Address_space_layout_randomization https://en.wikipedia.org/wiki/Address_space_layout_randomiza... for an overview on what this does. SMAP/SMEP: Intel/x86-specific security features. See http://j00ru.vexillium.org/?p=783 http://j00ru.vexillium.org/?p=783 for an early (2011!) take on SMEP. (j00ru is great reading, in any case.) See https://lwn.net/Articles/517475/ https://lwn.net/Articles/517475/ for SMAP from LWN. PAN: Privileged Access Never, Basically ARM SMAP: https://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development https://community.arm.com/groups/processors/blog/2014/12/02/...
- rasz_pl 10y ago
  Most(except ro/no exec) of the stuff mentioned are poor band-aid after the fact just in case security by obscurity solutions :( Whats worse some of them add baggage of kludges and cost extra processing, all in the name of slowing down attacker (not stopping, slowing down). This is why Linus was mostly skeptical if not opposing this (and grsec).
  - pjmlp 10y ago
    And all of them are band-aid for keeping to use monolith OSes written in C.
  - viraptor 10y ago
    I'd still add overflow protection to the good changes. If there's a counting logic error, there's not much you can do apart from locking down access to the resource. Provided you're already using a language that doesn't prevent it of course.
Animats 10y ago
They mention the downside of address space randomization - it kills bug repeatability. The effort to reproduce a crash is much higher. The result is bugs closed with "cannot reproduce" comments from developers. At least they're trying to reduce the attack surface. But the kernel is just too big.
- frederikvs 10y ago
  Couldn't they do something that's "repeatably random"? So that in case of a bug, you can extract some information from your kernel on its current randomisation, and then another kernel can use this information to repeat your random layout. E.g. use pseudorandom numbers, store the seed somewhere. In case of a bug, extract that seed, pass it on to the dev, and he'll run his kernel with that seed to reproduce.
  - DasIch 10y ago
    How do you prevent an attacker from getting the seed? This would just create a possible attack vector that could be used to effectively disable address space randomization.
    - frederikvs 10y ago
      e.g. only root can get access to the seed. Then the attacker would already need to have root, so then you're in huge trouble anyways. And yes, it may be weaker than a full-random solution. But a pseudorandom system that gets accepted is more secure than a full-random system that doesn't get accepted.
  - kodroid 10y ago
    This would sort of negate the purpose of ASLR, as afaik the whole point is an attacker would not know the mem layout. The very fact its not reproducible is the solution and the problem!
    - eeZah7Ux 10y ago
      No. If the seed would be made available only in a kernel bug report.
willvarfar 10y ago
(I'm on the Mill team :) ) Its good to see classic ISAs moving away from memory protection 'rings' towards arbitrary 'zones', even if retrofitting it e.g. SMEP/SMAP gives horrendous APIs and a nightmare to keep checked and balanced! ;) The Mill comes at this from the other direction, starting with 'zones' (termed "turfs" in Mill jargon) and emulating 'rings' (if your kernel wants that) with overlapping access rights between turfs. On the Mill you can have lots of turfs that may or may not have disjoint memory access, and you move between turfs synchronously with a special kind of indirect function call termed a "portal". There are provisions for passing across specific transient rights to memory in these calls, so you can pass a pointer to a buffer and other aspects that facilitate the 'usercopy()' mentioned in the article but with full hardware rather than software protection. We have tightened the portal/turf concept extensively since the Security talk http://millcomputing.com/docs/#security http://millcomputing.com/docs/#security but it does give a gentle high-level intro to turfs and portals. These days, we have facilities for passing buffers without exposing memory pointers and other niceties to make it easy to write correct yet efficient code. They can now all be made public but oh so little time, and I'm hoping to get a white paper out about it by the end of this month. Watch this space ;) Happy to elaborate if anyone has Mill or general questions :) PS an example of 'zoning' is http://elfbac.org/ http://elfbac.org/ , which is not getting enough attention. Its another way facilitate memory separation, albeit by abusing the classic MMU and with inherent runtime cost. Elfbac is userspace, but the hardware could be abused to protect kernels on classic CPUs too. Well worth everyone reading :)
- anonymousDan 10y ago
  Looks pretty cool. Out of interest, have you considered adding support for something like the enclaves provided by Intel SGX, e.g. for cloud computing use cases?
  - willvarfar 10y ago
    Yes, although we put that into our "virtualization" bag which we haven't begun mapping out in detail yet. I do try and keep up with the SGX roadmap and exploits; there have been some truly awesome attacks on it via hyperthreading, for example :) It will be interesting to see what AMD Zen does in this direction too. When the Mill is made, there will be all these orthogonal systems needed for these kind of use-cases available, but they won't pollute the portable ISA proper.
antocv 10y ago
I urge everyone to use linux-grsec, and avoid the security hole that vanilla kernel is. This stuff has been there in grsecurity patchsets for more than 10 (ten) years already.
- omginternets 10y ago
  What's the easiest way to start?
  - majewsky 10y ago
    Some distributions carry kernel images with the patchset, e.g. https://wiki.archlinux.org/index.php/Grsecurity https://wiki.archlinux.org/index.php/Grsecurity
    - ckastner 10y ago
      Debian recently started providing such images as well: https://packages.debian.org/search?keywords=linux-image-grsec https://packages.debian.org/search?keywords=linux-image-grse... https://wiki.debian.org/grsecurity https://wiki.debian.org/grsecurity
  - antocv 10y ago
    Use alpine linux on your servers, it uses grsec by default, and if you can bear it - even on desktop with xfce4. ArchLinux has linux-grsec as a package, its enough to pacman -S linux-grsec linux-grsec-headers and boot into it.
  - servilio 10y ago
    I can recommend Debian as well, used its grsec flavour of the Linux kernel package for a few months on my desktops successfully. I would recommend taking a look at NixOS as well, they have it integrated and it can be as easy as adding an option to your system configuration. If you further add any customization, you will get a unique kernel build for your system, what is said to be ideal security-wise. You can read the details on their manual: http://nixos.org/nixos/manual/index.html#sec-grsecurity http://nixos.org/nixos/manual/index.html#sec-grsecurity
contingencies 10y ago
The reality is that the majority of systems out there use distribution vendor supplied kernels. If you are in this camp, note that one of the best things you can do for kernel security in production is run a custom kernel with all of the features you don't need removed. If you go this route, definitely consider grsec as well. Reasonably tuning your kernel can also offer speed (eg. via more specific CPU targeting), size and - critically for embedded environments - startup time improvements.
- yitchelle 10y ago
  > critically for embedded environments - startup time improvements. This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH. Hopefully, the bootup time is in the subseconds by now. Are we getting to these speed yet?
  - _pmf_ 10y ago
    > This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH. The older NAND file systems were very slow. I've had a similar case where repartitioning the huge NAND into a smaller partition and only using a small partition reduced the boot time to 10 seconds without any other change. Modern UBIFS systems apparently don't have this problem. As for subsecond boot times: no chance with Linux.
    - yitchelle 10y ago
      Just looked up what UBIFS is, and saw the reference to JFFS2. We tried JFFS, it was painfully slow. JFFS2 was emerging and tried that too. In reality, it did not really worked for booting up. Once it was up, it was pretty good. Unfortunately, we were developing a hand hand consumer electronics device, so boot up times were absolutely critical.
    - rkeene2 10y ago
eugeneionesco 10y ago
Don't waste your time with vanilla if you really care about security, just use grsec.
- viraptor 10y ago
  This would be great, but unless you've got a budget for support, you probably shouldn't do it. When they say the free version is for testing, they mean it. Probably on servers it's less likely, but on desktop it has a tendency to crash xorg every few versions.
llihs0 10y ago
yet another grsec shill thread.
- bronson 10y ago
  Neither Corbet or Cook could ever be considered grsecurity shills. Honest question: did you read the article?
  - digi_owl 10y ago
    He may not be talking about the LWN stuff, but about the comments on HN. Most of the root comments are pitching grsec in some way or other...
- sctb 10y ago
  You're not allowed to post baseless accusations of shillage on Hacker News.
w8rbt 10y ago
I've been experimenting with Tomoyo Linux lately. To me, it's the simplest LSM to reason about (although I have misconfigured it before). In the spirit of Russell Coker's SELinux play machine, I have an initial Tomoyo test machine that users may experiment with as root (uid 0). Feel free to ssh in and try it out. If you find an issue, or bypass Tomoyo somehow, please don't damage anything and let me know. Also, please no fork bombs. You don't need root to do that: ssh -x -a root@montani.w8rbt.org Password = tomoyo1 Also, if you want to share this information with a friend, please use this URL: http://w8rbt.org/montani/
acobster 10y ago
> Probabilistic protections can be defeated if the information leaks out, but they are still effective and worth doing. What is the argument here? Is there something about this randomization that distinguishes it from classic security through obscurity?
- willvarfar 10y ago
  Exploit mitigation may be all that stops a vulnerability being successfully exploited. Here are some excellent slides on exploit mitigation in general: https://events.yandex.com/events/ruBSD/2013/talks/103/ https://events.yandex.com/events/ruBSD/2013/talks/103/ Of the top of my head there are four approaches to stopping memory vulnerabilities: 1) have no bugs, e.g. formal verification etc 2) use a memory-safe language 3) accept that there can be vulnerabilities, and use exploit mitigation to harden it 4) capability-based addressing as a mitigation (it doesn't solve use-after-free, for example; it relies on software to do that etc) Of these, (3) is the one you can retrofit to existing C/C++ codebases... a route you are usually forced to travel. (There may still be other kinds of bugs, e.g. the obvious sql injections etc; I am talking above about memory bugs specifically)
  - acobster 10y ago
    Yeah, makes sense. Thanks for the link.
- commenting 10y ago
  Security through obscurity can be very useful. It just shouldn't be the only thing you rely on to secure your systems.
  - acobster 10y ago
    Totally agree. I just don't know too much about kernel security and wanted to clarify whether this was mitigation via stc or something else.
tonyplee 10y ago
I love to see Linux Kernel, distributions put more focus on easy program / workflow that detect of insecure behaviors. (Good old ZoneAlarm type GUI / workflow would be very nice.) * Report and block if someone able to run any kind of privilege escalation exploit. * Report and block if any non-white list apps attempt to make any network connections to internet and any external IP. * Report and block if any non-white list apps, scripts try to run and execute any program. Selinux seems to claim it can do most of these. But the barrier of entry to setup and using it effectively is high (at lease for noob like me).
- mixedCase 10y ago
  Please read on RBAC. If you don't want to learn SELinux you can use AppArmor or grsecurity's RBAC system.

214 points by cheiVia0 10y ago

Prepare for the lovely blog post from the grsecurity author who is going to proclaim how he is so much smarter than everyone else, and that upstream Linux doesn't know what they're doing. /sigh

nwmcsween 10y ago
grsec will sadly slowly become irrelevant, they could have worked with mainline but instead acted like little spoiled children.
- micaksica 10y ago
  I disagree with this statement. grsec has been a proving ground for a lot of hardening technologies throughout the years, many of which are just starting to make it upstream through the Linux kernel political process. As long as the team that works on the grsecurity patchsets continues to innovate, it will not become irrelevant; instead, it will continue to be a testbed for things mainline will pick up and re-implement at their discretion.
  - nwmcsween 10y ago
    You seem to think grsec isn't in Linux due to the politics of submitting patches, grsec hasn't submitted piecemeal patches and their attitude is to derail conversations into name-calling. I recommend reading the comments in: http://lwn.net/Articles/663474/ http://lwn.net/Articles/663474/ or really anything where grsec team interacts with people. You can be the most intelligent human alive but if you cannot interact with people in a productive way it doesn't matter.
voidz 10y ago
What an non-constructive, cynical, depressing response. Grsecurity is a good product, components have been added to the kernel without proper attribution, and although Brad can admittedly add drama, how is this different from the drama your post adds? Pot, meet kettle.

totalZero 10y ago

I feel like such a moron when I read stuff like this, because I don't know what half the acronyms and technologies even are.

NetOpWibby 10y ago
Lmao, same.
micaksica 10y ago
KASLR: Kernel Address Space Layout Randomization. See https://en.wikipedia.org/wiki/Address_space_layout_randomization https://en.wikipedia.org/wiki/Address_space_layout_randomiza... for an overview on what this does. SMAP/SMEP: Intel/x86-specific security features. See http://j00ru.vexillium.org/?p=783 http://j00ru.vexillium.org/?p=783 for an early (2011!) take on SMEP. (j00ru is great reading, in any case.) See https://lwn.net/Articles/517475/ https://lwn.net/Articles/517475/ for SMAP from LWN. PAN: Privileged Access Never, Basically ARM SMAP: https://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development https://community.arm.com/groups/processors/blog/2014/12/02/...
rasz_pl 10y ago
Most(except ro/no exec) of the stuff mentioned are poor band-aid after the fact just in case security by obscurity solutions :( Whats worse some of them add baggage of kludges and cost extra processing, all in the name of slowing down attacker (not stopping, slowing down). This is why Linus was mostly skeptical if not opposing this (and grsec).
- pjmlp 10y ago
  And all of them are band-aid for keeping to use monolith OSes written in C.
- viraptor 10y ago
  I'd still add overflow protection to the good changes. If there's a counting logic error, there's not much you can do apart from locking down access to the resource. Provided you're already using a language that doesn't prevent it of course.

Animats 10y ago

They mention the downside of address space randomization - it kills bug repeatability. The effort to reproduce a crash is much higher. The result is bugs closed with "cannot reproduce" comments from developers. At least they're trying to reduce the attack surface. But the kernel is just too big.

frederikvs 10y ago
Couldn't they do something that's "repeatably random"? So that in case of a bug, you can extract some information from your kernel on its current randomisation, and then another kernel can use this information to repeat your random layout. E.g. use pseudorandom numbers, store the seed somewhere. In case of a bug, extract that seed, pass it on to the dev, and he'll run his kernel with that seed to reproduce.
- DasIch 10y ago
  How do you prevent an attacker from getting the seed? This would just create a possible attack vector that could be used to effectively disable address space randomization.
  - frederikvs 10y ago
    e.g. only root can get access to the seed. Then the attacker would already need to have root, so then you're in huge trouble anyways. And yes, it may be weaker than a full-random solution. But a pseudorandom system that gets accepted is more secure than a full-random system that doesn't get accepted.
- kodroid 10y ago
  This would sort of negate the purpose of ASLR, as afaik the whole point is an attacker would not know the mem layout. The very fact its not reproducible is the solution and the problem!
  - eeZah7Ux 10y ago
    No. If the seed would be made available only in a kernel bug report.

willvarfar 10y ago

(I'm on the Mill team :) ) Its good to see classic ISAs moving away from memory protection 'rings' towards arbitrary 'zones', even if retrofitting it e.g. SMEP/SMAP gives horrendous APIs and a nightmare to keep checked and balanced! ;) The Mill comes at this from the other direction, starting with 'zones' (termed "turfs" in Mill jargon) and emulating 'rings' (if your kernel wants that) with overlapping access rights between turfs. On the Mill you can have lots of turfs that may or may not have disjoint memory access, and you move between turfs synchronously with a special kind of indirect function call termed a "portal". There are provisions for passing across specific transient rights to memory in these calls, so you can pass a pointer to a buffer and other aspects that facilitate the 'usercopy()' mentioned in the article but with full hardware rather than software protection. We have tightened the portal/turf concept extensively since the Security talk http://millcomputing.com/docs/#security http://millcomputing.com/docs/#security but it does give a gentle high-level intro to turfs and portals. These days, we have facilities for passing buffers without exposing memory pointers and other niceties to make it easy to write correct yet efficient code. They can now all be made public but oh so little time, and I'm hoping to get a white paper out about it by the end of this month. Watch this space ;) Happy to elaborate if anyone has Mill or general questions :) PS an example of 'zoning' is http://elfbac.org/ http://elfbac.org/ , which is not getting enough attention. Its another way facilitate memory separation, albeit by abusing the classic MMU and with inherent runtime cost. Elfbac is userspace, but the hardware could be abused to protect kernels on classic CPUs too. Well worth everyone reading :)

anonymousDan 10y ago
Looks pretty cool. Out of interest, have you considered adding support for something like the enclaves provided by Intel SGX, e.g. for cloud computing use cases?
- willvarfar 10y ago
  Yes, although we put that into our "virtualization" bag which we haven't begun mapping out in detail yet. I do try and keep up with the SGX roadmap and exploits; there have been some truly awesome attacks on it via hyperthreading, for example :) It will be interesting to see what AMD Zen does in this direction too. When the Mill is made, there will be all these orthogonal systems needed for these kind of use-cases available, but they won't pollute the portable ISA proper.

antocv 10y ago

I urge everyone to use linux-grsec, and avoid the security hole that vanilla kernel is. This stuff has been there in grsecurity patchsets for more than 10 (ten) years already.

omginternets 10y ago
What's the easiest way to start?
- majewsky 10y ago
  Some distributions carry kernel images with the patchset, e.g. https://wiki.archlinux.org/index.php/Grsecurity https://wiki.archlinux.org/index.php/Grsecurity
  - ckastner 10y ago
    Debian recently started providing such images as well: https://packages.debian.org/search?keywords=linux-image-grsec https://packages.debian.org/search?keywords=linux-image-grse... https://wiki.debian.org/grsecurity https://wiki.debian.org/grsecurity
- antocv 10y ago
  Use alpine linux on your servers, it uses grsec by default, and if you can bear it - even on desktop with xfce4. ArchLinux has linux-grsec as a package, its enough to pacman -S linux-grsec linux-grsec-headers and boot into it.
- servilio 10y ago
  I can recommend Debian as well, used its grsec flavour of the Linux kernel package for a few months on my desktops successfully. I would recommend taking a look at NixOS as well, they have it integrated and it can be as easy as adding an option to your system configuration. If you further add any customization, you will get a unique kernel build for your system, what is said to be ideal security-wise. You can read the details on their manual: http://nixos.org/nixos/manual/index.html#sec-grsecurity http://nixos.org/nixos/manual/index.html#sec-grsecurity

contingencies 10y ago

The reality is that the majority of systems out there use distribution vendor supplied kernels. If you are in this camp, note that one of the best things you can do for kernel security in production is run a custom kernel with all of the features you don't need removed. If you go this route, definitely consider grsec as well. Reasonably tuning your kernel can also offer speed (eg. via more specific CPU targeting), size and - critically for embedded environments - startup time improvements.

yitchelle 10y ago
> critically for embedded environments - startup time improvements. This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH. Hopefully, the bootup time is in the subseconds by now. Are we getting to these speed yet?
- _pmf_ 10y ago
  > This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH. The older NAND file systems were very slow. I've had a similar case where repartitioning the huge NAND into a smaller partition and only using a small partition reduced the boot time to 10 seconds without any other change. Modern UBIFS systems apparently don't have this problem. As for subsecond boot times: no chance with Linux.
  - yitchelle 10y ago
    Just looked up what UBIFS is, and saw the reference to JFFS2. We tried JFFS, it was painfully slow. JFFS2 was emerging and tried that too. In reality, it did not really worked for booting up. Once it was up, it was pretty good. Unfortunately, we were developing a hand hand consumer electronics device, so boot up times were absolutely critical.
  - rkeene2 10y ago

eugeneionesco 10y ago

Don't waste your time with vanilla if you really care about security, just use grsec.

viraptor 10y ago
This would be great, but unless you've got a budget for support, you probably shouldn't do it. When they say the free version is for testing, they mean it. Probably on servers it's less likely, but on desktop it has a tendency to crash xorg every few versions.

llihs0 10y ago

yet another grsec shill thread.

bronson 10y ago
Neither Corbet or Cook could ever be considered grsecurity shills. Honest question: did you read the article?
- digi_owl 10y ago
  He may not be talking about the LWN stuff, but about the comments on HN. Most of the root comments are pitching grsec in some way or other...
sctb 10y ago
You're not allowed to post baseless accusations of shillage on Hacker News.

w8rbt 10y ago

I've been experimenting with Tomoyo Linux lately. To me, it's the simplest LSM to reason about (although I have misconfigured it before). In the spirit of Russell Coker's SELinux play machine, I have an initial Tomoyo test machine that users may experiment with as root (uid 0). Feel free to ssh in and try it out. If you find an issue, or bypass Tomoyo somehow, please don't damage anything and let me know. Also, please no fork bombs. You don't need root to do that: ssh -x -a root@montani.w8rbt.org Password = tomoyo1 Also, if you want to share this information with a friend, please use this URL: http://w8rbt.org/montani/

acobster 10y ago

> Probabilistic protections can be defeated if the information leaks out, but they are still effective and worth doing. What is the argument here? Is there something about this randomization that distinguishes it from classic security through obscurity?

willvarfar 10y ago
Exploit mitigation may be all that stops a vulnerability being successfully exploited. Here are some excellent slides on exploit mitigation in general: https://events.yandex.com/events/ruBSD/2013/talks/103/ https://events.yandex.com/events/ruBSD/2013/talks/103/ Of the top of my head there are four approaches to stopping memory vulnerabilities: 1) have no bugs, e.g. formal verification etc 2) use a memory-safe language 3) accept that there can be vulnerabilities, and use exploit mitigation to harden it 4) capability-based addressing as a mitigation (it doesn't solve use-after-free, for example; it relies on software to do that etc) Of these, (3) is the one you can retrofit to existing C/C++ codebases... a route you are usually forced to travel. (There may still be other kinds of bugs, e.g. the obvious sql injections etc; I am talking above about memory bugs specifically)
- acobster 10y ago
  Yeah, makes sense. Thanks for the link.
commenting 10y ago
Security through obscurity can be very useful. It just shouldn't be the only thing you rely on to secure your systems.
- acobster 10y ago
  Totally agree. I just don't know too much about kernel security and wanted to clarify whether this was mitigation via stc or something else.

tonyplee 10y ago

I love to see Linux Kernel, distributions put more focus on easy program / workflow that detect of insecure behaviors. (Good old ZoneAlarm type GUI / workflow would be very nice.) * Report and block if someone able to run any kind of privilege escalation exploit. * Report and block if any non-white list apps attempt to make any network connections to internet and any external IP. * Report and block if any non-white list apps, scripts try to run and execute any program. Selinux seems to claim it can do most of these. But the barrier of entry to setup and using it effectively is high (at lease for noob like me).

mixedCase 10y ago
Please read on RBAC. If you don't want to learn SELinux you can use AppArmor or grsecurity's RBAC system.