Submitted by “In Red Hat Enterprise Linux 4, 15 services in system space had confined SELinux domains defined. In Red Hat Enterprise Linux 5, over 200 processes are confined by SELinux. The improved SELinux policy is much more precise in how it governs the operation of these services. It’s far less likely that a Red Hat Enterprise Linux 5 system space process will be compromised or encounter an error caused by an SELinux policy not handling the specific requirements (e.g., file or directory access) of a service.”
That was a great read. Well structured and comprehensive.. Handy too, (I normally disable SELinux), but as I install Centos 5.0, this time I will think differentlyTM.
One’s you get in kernel, nothing can protect you.
Vista takes the first step here on verifiable kernel by using patch guard and signing but this is still a long road to go to achieve near perfection.
Once you have permissions to load a kernel driver in linux you’re screwed anyway. That’s why Linux developers put all their efforts into forbiding hackers from getting privileges to load drivers.
BTW, Linux has a even STRONGER solution to “patch guard”. It’s called: “compile everything into the core, disable module loading”
Are you suggesting to build a kernel with 100s of drivers loaded. Anyways i was not talking about this.
I was talking about kernel exploits i.e. if a kernel driver has a bug it is very easy to execute code in kernel even when you don’t install a driver.
Vista protect against many such attacks and with /GS and NX option makes it much harder to do buffer overflow attacks.
Tell me something similar in Linux instead of telling me to compile everything and make a fat kernel. That is IMO going backwards.
http://fedoraproject.org/wiki/Security/Features
http://www.awe.com/mark/blog/200701041544.html
As for SELinux kernel and memory security; these are the main settings I use with the targeted or strict policies under enforcing mode:
Do not allow any processes to load kernel modules (may need to be enabled depending on your needs)
Do not allow any processes to modify kernel SELinux policy (good idea to disable this when doing SELinux policy updates then re-enable after)
Do not allow unconfined executable to make their heap memory executable
Do not allow unconfined executable to make their stack executable
Do not allow unconfined executables to map a memory as both executable and writable.
Do not allow unconfined to dyntrans (change) to unconfined_execmem
With this you end up with badly or evil written software not working, so you manually decide which ones you trust and override their file security context with chcon.
Edited 2007-05-05 20:59
Thanks for the links. This is indeed good information. I did not know that all the protections are by default ON in redhat. I knew about exec.shield but i did not know if it is already included.
Good to know this.
Funny thing, SELinux blocked this *0day Linux Kernel Exploit* on my RHEL4 server at the time. The second that email hit my inbox from the full-disclosure list, I tried out that code on some dev server and it was blocked by SELinux.
http://seclists.org/fulldisclosure/2006/Jul/0312.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198973
So it looks like SELinux can prevent Linux kernel exploits
RHEL and Fedora also have provisions for restricting how kernel-mode memory is overwritten, thus killing many types of rootkits. Then there are things like PIE/ASLR and NX as part of Exec-Shield.
BTW, you can download the strict SELinux policy package if anyone is interested. Play with system-config-selinux and lock your system down so tight your balls will ache.
GRSecurity has mechanisms to prevent kernel exploits including the CONFIG_GRKERNSEC_KMEM option which prevents modifying a running kernel. If you then disable module loading and use the included RBAC system or one from another project, your kernel should be very secure. Security needs to be layered to be effective and things like CONFIG_GRKERNSEC_KMEM or Patchgaurd alone will not prevent kernel exploits.
Unfortunately GRSecurity is not in the mainline kernel and PatchGaurd is only available on seldom purchased 64-bit versions of Vista.
I’m a little tired right now, so I’m likely not reading this correctly:
Someone cracks into my httpd through some buggy module. She gets a shell and then uses a local priv escalation of some sort to get from the apache user to root. Using this “root shell” she still can’t access my database? How can SELinux do this? What if I’m a remotely logged in user who can sudo to root… do I still not have access to the database? What’s different between the two cases?
It is possible if your process that you launch through httpd inherits the security token of httpd (or whichever thing you compromise) which doesn’t have access to the database.
Ofcourse the concept is to divide the whole system into seperate container so that infection in one container doesn’t compromise the whole system.
That is why i said that this only works for user mode. Once you are in kernel nothing can protect you but well some linux fanboys modded me down:)
This sounds like it would only work for servers and daemons. Sometimes a user needs to be able to actually elevate the rights of some process which they launch. Seems like a good idea though. None of a restricted processes’ descendants can ever get higher privileges than it has. But isn’t this already the case with the inheritance of uid and gid?
I think the system is broken if you can go from user apache to root, in any case, but what is it about SELinux and its MAC implementation that does what the normal user-based separation does not?
I don’t know how it is done in SELinux but you technically one simplest way is what i presented.
Think that if httpd is running with a restricted security token then even if someone can find a flaw in some system API and use that API to elevate themselves to root, their security token would still not change. So even with root user account they would still have restricted token and thus won’t have access to do all “root” tasks.
Edited 2007-05-05 03:42
First off, it’s a layer of security on top of security.
Secondly, MAC stands for mandatory access control — the system administrator/security administrator sets the policy and is the only one who can control it.
DAC stands for discretionary access control — the user can control his resources.
SELinux through its MAC model allows the security admin to determine the permissions that a process has based on who started the process or what process launched the process. That type of granular control over permissions based on who or what is starting a process is not something allowed in the regular Linux system to my knowledge.
Sure, in DAC (traditional linux system), you could start a process as the apache user or the root user, but can you then control the specifics and have them apply to just that process?
Edit: Clarified my last statement and split it out from the last paragraph.
Edited 2007-05-05 03:48
This sounds like it would only work for servers and daemons. Sometimes a user needs to be able to actually elevate the rights of some process which they launch.
Ever used Fedora? SELinux has been on by default in Fedora since FC2. Granted, Fedora Core 2 was a disaster and they had to switch to the targetted policy at the last moment, but has been enabled on Linux desktops for some time.
Using the Targetted policy, only system level daemons are protected. Things like cron, syslog, logrotate, apache, bind, sshd, etc are protected where things like firefox are not (yet).
“””
That is why i said that this only works for user mode. Once you are in kernel nothing can protect you but well some linux fanboys modded me down:)
“””
I don’t usually respond to this kind of sneak attack, but it was probably because your post (the second one for this story) was intentionally designed to be provocative and was really only tangentially on topic, as SELinux is primarily about protecting the system from exposed services provided by user-space processes.
Don’t feign innocence. In addition to being obvious to others, it is unbecoming.
Personally, I wouldn’t have modded it down. But I can understand how others could very legitimately have done so.
I’m certainly not a Dan Walsh or Steve Grubb, but let me make an attempt here. SELinux is implemented at the kernel level and enforces policy through SELinux types. These types are checked between the source context (could be the process you cracked) and the target context (most likely the file/process you are trying to crack). If the types don’t match what the policy allows, then SELinux through the kernel disallows the action.
In the case of httpd, you hack it and only have the running type of httpd_t. To do just about anything on the system, you will need a type other than httpd_t, which as type httpd_t, you are not allowed to change. It’s all somewhat complex (and not only about type), but essentially through these confined domains, you lock a cracker into an incredibly difficult area.
So in your example, the local priv escalation script wouldn’t work. In the domain httpd_t, you would not be allowed to gain “true root”. SELinux Policy would keep you from doing that — which is how SELinux can make the claim that it stops “zero-day exploits”.
I think I see now from what you’ve explained: there’s a process (or task) level security mechanism. Any application (be it one or more processes) gets labelled with what it’s doing. If your application doesn’t need many rights, you just give it access to only the things it needs, even though the user might have access to more.
This sounds like a good way to separate the processes a user is running into finer-grained security boundaries. I hope the administrative burden is not too great…
The administrative burden isn’t terrible — especially going with pre-written policies like the targeted policy in SELinux. However, there is a learning curve to SELinux, but Red Hat has some good documentation available here:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deploym…
Chapters 43-45 are great starts into SELinux and RHEL5 from an administrative and end user point of view.
Excellent work on Red Hat’s part to attempt to make selinux auditing messages friendlier. The front-end config tool looks pretty nice too.
I’m normally not a fan of “dumbing down” efforts like this, but selinux is obscure enough in the tools to implement it that I believe most folks simply turn it off. That’s a shame because MAC would go a long way in disabling zero-day flaws / attacks.
I look forward to playing around with RHEL 5 (or at least CentOS 5) soon.
The first critical comment in the article is rather interesting too. In summary the writer says that SELinux’s guarantees aren’t worth as much as they claim to be. The link in the comment goes here: http://lists.immunitysec.com/pipermail/dailydave/2007-March/004133….
Any comments on that?
Edited 2007-05-05 05:43
Any comments on that?
Yes, grscurity is something that their authors have been wanting to merge into the kernel without success, because their view in how security must be done is quite different from the kernel maintainers
Edited 2007-05-05 13:50
A new article at Search Enterprise Linux: “Five ways SELinux may surprise you”, is a good introduction to the potential of SELinux.
http://searchenterpriselinux.techtarget.com/columnItem/0,294698,sid…