Red Hat Seeks to Deliver Most Secure Linux 262
Jack writes "ITO is running a story on Red Hat's plan to become the most secure Linux platform. From the article: "Red Hat officially joined The National Information Assurance Partnership to bring an improved level of security and assurance to Linux. This means that the next version of Red Hat Enterprise Linux will contain kernel and Security Enhanced Linux policy enhancements, developed by IBM, Red Hat, TCS, NSA and the community.""
Re:Is this a magnet? (Score:5, Informative)
Regards,
Steve
Re:Missed a link :) (Score:4, Informative)
Maybe this was intended as a joke, but it's a valid point. SELinux does not make anything more secure. Why? Because it's sufficiently complicated that most people are just going to turn it off. OpenBSD has a policy that security must be on by default, must not create a significant performance hit, and must be simple enough that people actually use it. This is the reason people trust it.
Indeed, something like http://pax.grsecurity.net/ [grsecurity.net] is clearly useful, but breaks too many applications, is a kernel patch to the standard kernel that you have to apply yourself, so it's not so widely used. Neither SuSE nor RedHat supports it. OpenBSD does similar things, but they make sure that the ports and the system does not break. As a OpenBSD you don't have to do anything special, apart from installing OpenBSD, to take advantage of the security enhancements.
Trustix (Score:5, Informative)
Re:OpenBSD (Score:4, Informative)
Judging from the technologies and companies mentioned in the summary, this attempt at Linux security is based on providing better access controls and privilege models in the Linux kernel. By better, I mean that these mechanisms can:
1) Provide finer grain privileges so that fewer programs can be exploited to escalate privilege, and
2) Isolate unrelated programs and users from each other (e.g. an exploit in a DNS server is restricted to only accessing DNS files but is not able to manipulate web server pages).
These two techniques basically reduce the number of avenues an attacker can use to exploit a system. It is less likely that a piece of exploitable software will have sufficient access to whatever it is the attacker wants to get to. Granted, it is not a complete solution, but it's a handy thing to have in one's security toolbox.
I believe that the OpenBSD/OpenSSH teams are beginning to do similar things (e.g. OpenSSH privilege separation), but I don't think they've taken the leap to providing more sophisticated access controls in the kernel.
If you're interested, examples of trusted operating systems/access controls can be found at the following places:
Linux Capabilities:
http://ftp.kernel.org/pub/linux/libs/security/lin
Trusted BSD:
http://www.trustedbsd.org/docs.html [trustedbsd.org]
Argus Systems Group (go to the Support section and take a look at the docs for PitBull LX and Foundation; they give a rather complete description of the mechanisms):
http://www.argus-systems.com/ [argus-systems.com]
Trusted Computer Solutions (mentioned in the article):
http://www.trustedcs.com/index.html [trustedcs.com]
Disclaimer: I used to work for Argus Systems Group, and I know a few of the TCS employees (as they are also ex-Argus employees).
Re:OpenBSD (Score:1, Informative)
Because it's too complicated. People rave about this "ports" system, but what does it buy me that my Debian package repositories don't already have? When I tried to use OpenBSD it was a pain in the ass to upgrade, administer, and find applicatons for. I'll stick with Debian Linux.
The SELinux Devil... (Score:3, Informative)
1. Enabling it during install doesn't magically make every application SELinux aware. It turns out that packages need to have SELinux features. Here's a link to the good fellow doing SELinux packages for Debian. http://www.coker.com.au/selinux/ [coker.com.au] Now, I don't know if the Fedora package volunteers have done the same kind of work or not, but I'd be interested to hear either way. It reminds me of LDAP, where LDAP is good, but applications need to support it to make it great.
2. My experience turning on SELinux in FC was not good. I attempted to build a firewall with IDS and the IDS just didn't work. I'm not a coder, nor am I a really strong Linux Admin, so bye-bye SELinux and the firewall/IDS worked like it should.
3. Generally speaking, American PHB's (at least) are finally getting the message that IT security is far more important than in the past and I think this is a well-timed Marketing message with the actual SELinux implementation throughout FC being very far from their glossy claims.
Re:But SELinux SUCKS for enterprise (Score:2, Informative)
Re:OpenBSD (Score:3, Informative)
For example, I believe that the OpenBSD/OpenSSH teams are beginning to do similar things (e.g. OpenSSH privilege separation),
Privilege separation has been in OpenBSD for years. It is not something that OpenBSD is "beginning to do".
Bah! (Score:2, Informative)
Fortunately, my company is going to announce soon with an OS that truly is secure.
Flame away (again).
Because everything but the base system is painful (Score:3, Informative)
Those are my top three. OpenBSD is slick, and I love using it for applications where 99% of the functionality I need can be provided by the base system. For services that change rapidly, though, it's more of a hassle than I'm willing to put up with.
Secure Linux on the desktop? Sure (although I'd hate to give up my FreeBSD desktop system). OpenBSD on the desktop? Shoot me now.
Re:RedHat poised to become the next Microsoft (Score:1, Informative)
legal action based on TRADEMARK infringement. TRADEMARK law is very different than copyright law in the US. TRADEMARK law DEMANDS that a TRADEMARK holder actively defend the mark or the mark can lose its protected status and anyone..even competitors could then use that trademark to cause confusion in the marketplace.
Even the name "linux" has a TRADEMARK associated with it..and there is an organization called LMI that seeks to protect the linux TRADEMARK from being used inappropriately. http://www.linuxmark.org/ [linuxmark.org]
Its critical to understand the difference between TRADEMARKS and COPYRIGHT. LMI's webpages do a reasonable job trying to explain why TRADEMARK enforcement even for the term "linux" is important. Please make an effort to read and understand those pages. Its just as appropriate for a for-profit business to protect its marks as it is for a non-profit organization like LMI. If Red Hat doesn't want to offer a license to its competitors for use of the marks..and centos is a competitor...thats perfectly reasonable.
missing the point (Score:2, Informative)
-Nex6
-Nex6.blogspot.com
Re:Missed a link :) (Score:3, Informative)
http://www.redhat.com/magazine/009jul05/features/
Re:RedHat poised to become the next Microsoft (Score:3, Informative)
Please stop making it look like CentOS was a victim and Red Hat was a villain. CentOS chose a different course of action when several options were available to them. I'm really tired of seeing people not standing up for themselves but then turn around and act like they're getting pushed around.
Re:Missed a link :) (Score:4, Informative)
Ever hear of W^X (write xor execute)? Randomized library base addresses? Propolice? Privilege seperation?
All these work to protect the system even in the event of buggy applications. OpenBSD does a lot more than just auditing the code in the base install.
Re: I didn't try hard enough so it sucks (Score:5, Informative)
Re: I don't know how to do it and therefore it can't be done and therefore it sucks.
It can be done. Here's how:
First some good documentation [redhat.com].
Run:
# up2date --install (or yum install) selinux-policy-targeted-sources /etc/selinux/targeted/src/policy
# cd
# make enableaudit
Run whatever service that is currently broken because of SELinux. Then:
# audit2allow -i /var/log/messages -l
allow httpd_t cifs_t:dir search;
allow httpd_t unlabeled_t:dir { getattr search };
...which will tell you where SELinux blocked the service. (Just some sample output here.)
Then add your own rules like this:
# cat >domains/misc/local.te <<EOF
allow httpd_t unlabeled_t:dir { getattr search read };
allow httpd_t unlabeled_t:file { getattr read };
allow httpd_t unlabeled_t:lnk_file { read getattr };
allow httpd_t cifs_t:dir { getattr search read };
allow httpd_t cifs_t:file { getattr read };
allow httpd_t cifs_t:lnk_file { read getattr };
allow httpd_t default_t:lnk_file { getattr read };
EOF
# make reload
The above is again just an example.
Try again. If it doesn't work you need to allow some more stuff, which audit2allow will tell you.
Re:selinux effectiveness (Score:4, Informative)
You are indeed wrong. OpenBSD includes a number of systems which make buggy code more secure. Some examples:
The OpenBSD team realises that no developer is infallible, and they work hard to ensure that security extends far beyond the base system. The work they've done on memory allocation alone is staggering - the diagrams I saw showing the before and after pictures of memory layout were staggering - and all of this was done to support a legacy architecture (x86) because a lot of people use it and they didn't want to force everyone to buy new NX-supporting chips to get the required protection.