The release of Red Hat Enterprise Linux 4 debuts the first commercially supported inclusion of Security-Enhanced Linux (SELinux). Russell Coker from the Red Hat SELinux team explains the default targeted policy.
Red Hat explains SELinux targeted policy
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Yes!
While an interesting read, I find it curious what RedHat will support in terms of configurations. The briefing I attended at work (hosted by RedHat) did not discuss support limitations to RHEL based on configuration of SELinux.
The person giving the brief wasted no time in “busting on” Sun and Solaris mentioning that Trusted Solaris is not up to the same OS level as Solaris or Solaris Express (Trusted 8/Solaris 10). Never mind the same revision issue exists with AIX (Trusted AIX 4.1.3 vs. AIX 5L 5.3). As if that really mattered since many of the features of Solaris 10 came from Trusted Solaris. Furthermore SELinux provides no support for Labeled Security, which if you are trying to sell to the Government is a primary requirement. Especially if you are trying to sell to a customer who uses Trusted Solaris (we do).
I asked about an article I read on Phrack about using “evil” kernel modules to root machines (Solaris, Linux, BSD) the person giving the brief said SELinux does provide protection against attacks using modules, if configured for it. He said “all bets are off” if your security policy allows for addition or removal of kernel modules.
While I am for any improvement in security, I don’t like the idea of being boxed in to achieve it. I also don’t necessarily think that Mandatory Access Control is necessary to get good security. For organizations that require that level of control, it is a definite improvement and hopefully RedHat will “loosen up” on its support for “custom” configurations.
security in IT systems is not only about access control. a firewall or a permission system does not a secure system make.
security is about privacy, integrity (of data and source), availability (what good is a DOSed system even if the attackers don’t see private information or modify data), and accountability (non-repudation).
the problem with IT security is that it is product and technology led.
you don’t see finance led by software products or technologies. finance has sound principles and solutions are chosen to meet the policies, not the other way around.
sigh.
Maybe I’m misunderstanding, but rhel 3 has had eal3 certification for a while now, and rhel 4 is under consderation for eal4 certification. I have no doubt they’ll get it. They have some pretty bright employees working for them to say the least.
However, I will agree that Red Hat support kinda stinks in that they won’t support some custom selinux setup. But then again I’d imagine they would if you paid them enough money.
But man, you’re saying mac isn’t necessary for good security? I guess that is the OpenBSD point of view, which I disagree with mind you…but don’t the eal certs that you were talking about in the first place require that?
Actually, no they don’t. If you look up the Trusted Computer Security Evaluation Criteria (of 1985) the C2 (now CC EAL3) is the minimum evaluation level for the processing of Top Secret information. Notice that I say minimum here. What drives the security level is the amount of auditing of user actions that is required at each security level.
Operating systems evaluated at EAL3 and 4 use for the most part Discretionary Access Control (Solaris/AIX/HP-UX/Windows 2000/SuSe Linux). Mandatory Access Control is primarily used for what is called Multiple Label Security (or MLS). This level requires an operating system to work at TCSEC B or A level security (or CC EAL4+ and higher equivalent).
Trusted operating systems cost more, considerably more than their untrusted counterparts. The certification process is far more rigorous not only for the OS, but the patches as well. This is an example of security with no regard for cost, to install Trusted Solaris on a datacenter quality server (using the Certified Edition) the cost would be $79,495.00! This is per machine, not per site. This is the primary reason why you do not see wide scale deployments of Trusted Solaris or AIX.
“Furthermore SELinux provides no support for Labeled Security, which if you are trying to sell to the Government is a primary requirement. Especially if you are trying to sell to a customer who uses Trusted Solaris”
If you mean by Labeled security, MLS then its likely to be supported in a upcoming version of SELinux. SELinux is very much in active development.
“security in IT systems is not only about access control. a firewall or a permission system does not a secure system make. ”
its not just about these but all of the above has a significant effect on the general security of the system
“However, I will agree that Red Hat support kinda stinks in that they won’t support some custom selinux setup. But then again I’d imagine they would if you paid them enough money. ”
Targetted policy that is being supported in SELinux does not require too much hand holding but strict policy would so Red Hat would require experts to work with customers on resolving those issues. That can pretty much be arranged but you guessed right about the support cost being higher
” What drives the security level is the amount of auditing of user actions that is required at each security level. ”
right on target. This kind of auditing requires kernel code and framework (which sort of exists already as patches) . When it gets upstream, its likely to be on the next update of RHEL following that. Based on the audit framework, it would be possible to pursue certifications
I agree, this is a start,although a good one.
Somebody has to start taking the bull by the horns (no pun intended).SeLinux is one of the many tools in the chain with which you can take the system security to a higher level.Very good start.
Even though its nice to see that Red Hat is starting to support SELinux the targeted policy is to lax. It only covers server stuff. In a way that makes sense as they aim for that market, but I think they should cover tools that a sysadmin might use while administrating the system. E.g. e-mail clients and web browsers as well.
It only covers server stuff
I agree,however it has to start somewhere where it’s an necessity and later it becomes avaible where it is a additional sec feature.For servers i would rather prefer the white listing aproach of Grsecurity,whereas SELinux blacklists .
but I think they should cover tools that a sysadmin might use while administrating the system. E.g. e-mail clients and web browsers as well.
If the admin doesn’t admister his stuff with via a dedicated terminal without,preferrably in the server room itself, X.
“but I think they should cover tools that a sysadmin might use while administrating the system. E.g. e-mail clients and web browsers as well.”
support for browsers and other client side software is under development but considering the fact that Linux has more deployments as a server currently and that network facing deamons are more vulnerable to exploits it seems that that this is a fair compromise to make.
Wow! SELinux is great, but read the whitepaper by Arjan. Apparently execshield was able to stop something like 75% of exploits that came out between Nov 1st 2003 and August 11th 2004. What’s more the ones it didn’t stop were kernel exploits.
In other words, execshield had a 100% success rate at repelling exploits for the attacks it was designed for – on non-NX hardware. That’s pretty awesome, congrats to Ingo Molnar and the others at Red Hat for a job well done!
If you are using SELinux correctly and have “jailed” the root account, or created a role for root there should be no problem. The concept of Least Privilege was discussed in the TCSEC in 1985 and for the most part the *nix people get it. It has taken Microsoft over 20 years to realize that you can’t run everything as SYSTEM and be secure.
Where’s the link to the article?
Here is the white paper
http://people.redhat.com/mingo/exec-shield/docs/WHP0006US_Execshiel…
Other security features
http://people.redhat.com/mingo/exec-shield/docs/nonselsec.pdf
One small obstacle to take,xorg or xfree86 still runs in the admin context when you don’t do a manually startx from your user context,which is pratically everywhere the case on the average Linux desktop?
Rahul,
Thanks, the first link worked and second I got a 403 error. Do you have another link for the second document that works?
I think they have protected against direct linking
You have to go to:
http://people.redhat.com/mingo/exec-shield/docs/
I got:You don’t have permission to access /mingo/exec-shield/docs/nonselsec.pdf on this server.
But i could download it while being at the aforementioned link.
What’s the reference above to Solaris 10 being based on Trusted Solaris? Where can I learn more about this? Any good comparisons of Trusted Solaris to SELinux?
Solaris 10 features such as Role Based Access Control (RBAC), the ppriv command came straight from Trusted Solaris. Here you will find a review of Trusted Solaris:
http://www.samag.com/documents/s=1769/sam0112i/0112i.htm
You might want to read my earlier posts concerning direct comparisons of SELinux to Trusted Solaris, but SELinux does not support Labeled Security, Trusted Solaris does.
Red Hat also provide strict policy.
Right now only targeted policy is enabled by default.