"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."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-01-02
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?
Member since:2005-07-10
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
Member since:2005-06-29
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
Member since:2005-11-05
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).
Member since:2005-07-24
"""
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.
Member since:
2005-07-10
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:)