Red Hat Seeks to Deliver Most Secure Linux
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.""
The article left out a hyperlink, corrected here :
Trolling is a art,
Why don't the security conscious just use OpenBSD?
When you're afraid to download music illegally in your own home, then the terrorists have won!
As sections of the Linux community, such as RedHat, start merging with big businesses, such as IBM, we have to wonder how long it will be before the Red Hat team starts walking on 2 legs...RedHat could be well on it's way to becoming the next Microsoft.
ITO is running a story...
...and probably running it as root, too, the stupid bastards.
Major corporations (such as oracle) target Linux; specifically RedHat. With RedHat, you gain all of the applications that already work with Linux plus security enhancements. With OpenBSD, even though they have a decent amount of applications, they have nowhere near the variety that Linux has, so that gives Redhat an edge.
Yes they do http://www.nsa.gov/selinux/info/faq.cfm#I2, the mentioned security enhancements are more like ACL's and policies.
Cavity searches.
Well Red Hat already is a key innovator into securing the kernel. As most know, Red Hat contributes more code to the kernel than any other entity. The kernel is their livelihood. SELinux patches work with the kernel now because Red Hat engineers worked closely with the SELinux NSA guys to get it to that point. Red Hat also created exec-shield which implements a number of security benefits including NX (NoExecute) and PIE (Position Independant Executables). They release both RHEL and Fedora with sane but secure SELinux policies, compile their major services with FORTIFY_SOURCE and other GCC options that find and/or block many types of overflows and other bugs. PIE is pretty neat in that it randomizes the memory layout so an attacker executing an attack can't know what memory lays ahead, often making the overflow useless. PIE has some performance impedements, so its only typically used on public facing services. Red Hat already forces yum and up2date to verify all gpg signatures by default, and they designed the RPM format so it is highly secure and you know what you're getting when you get it (gpg signing, double hashes (MD5 and SHA1 so that even if one is cracked, the other can act as a crutch until a new solution is found). Red Hat is also reknowned for getting security updates out sometimes days before others. Red Hat is responsible for many of those security patches, and one of the reasons Linux has such a good reputation for getting patches out quickly is a direct result of Red Hat. Anyway... if I had to put my money on someone doing this for Linux, Red Hat would be where I'd put it. They've already shown that they do much for the community, they gave us cygwin, they maintain GCC and libc, they created GCJ so we can run about 95% of java programs natively, including OpenOffice and Eclipse (albeit GCJ is still under heavy development), plus many more things from writing lots of code for projects like Apache and Gnome. (I can't forget to mention buying Netscape Directory Server and giving it to the community, as well as GFS, Global File System). Red Hat's legal department sometimes stirs trouble with derivatives using thier trademark, but the Red Hat engineers actively help CentOS and others. Red Hat is the only major linux player who depends on linux to succeed. All the others, IBM, Novell, Sun, etc.. have come onto the linux "train" to see if it can make them lots of money, if Linux fails however they'll just move on to the next big thing, like they've always done. Red Hat's entire being revolves around linux and its success, they have the motivation that is needed.
Regards,
Steve
Microsoft says it plans to create and ship the most secure version of Windows.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
First off, I should let it be known that I am a BSD fan, and not a Linux one. However, despite my many issues with Red Hat and Fedora Core, they have been integrating some really cool stuff of late, things I had wanted to have easy access to in a open source operating system for some time, such as the SELinux functionality.
It's absolutely fantastic work they are doing; making SELinux a default in their systems in meaningful ways, while at the same time, doing their damndest to make it as transparent as possible to the everyday user. No one else is doing that. OpenBSD are the kings of UNIX quality control, but they offer nothing in the way of mandatory access controls. FreeBSD has comparable technology in the form of the TrustedBSD MAC Framework (which is excelant), but they are not yet offering security policies that are transparent to ordinary users of the system, and like SELinux in most distributions that support it, it's a pain to set up correctly.
Now if only they (Fedora especially) would ship a basic "desktop install" on *one* CD image instead of requiring 2-4 CDs, my major gripes with their software would go away completely. This kind of hardcore but transparent security is most definately needed by everybody today, and right now, only Red Hat and the Fedora Project are providing it. As much as I prefer the saner development methodologies and more well thought out kernel architectures provided by the various BSDs, in an online world as inherrently dangerous as our own, employing an operating system that supports these security technologies is the only real way to go.
Come on FreeBSD! What are you waiting for? Keep up the (mostly) good work Fedora people!
Trustix Secure Linux has been one of the most secure distributions since its inception. No services are on by default and only a minimal install is needed most of the time. Updates come out seemingly hourly (more like daily) and it's one of the smoothest and securest server operating systems out there. If you're looking for desktop, you're not going to find it with Trustix. I've been using it as my main server distribution for ~3 years without a single problem.
Colin Dean Go a year without DRM
My Windows box has more security. It doesn't have internet. And it doesn't have an Enter key. Matter of fact, as long as I don't use it, don't let anyone else use it, and don't even turn it on, its secure as Fort Knox.
We need to act before that happens!
Let's get together and make sure that all new versions of software that RedHat sells are covered by some kind of license that prevents them from locking the software up! Hell...we could even include some kind of restriction that forces them to release any changes they make. That'll stop them!
Titanic... couldn't be sunk
Windows 2000... unhackable
RedHat Server 2007... uncrackable
Don't think so...
That is all.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
There are already a number of quality server distributions out there with security tools like SELinux, GRSecurity and PaX, but it will be interesting to see Redhat contribute to the mix. Personally, I use a number of modified Redhat patches while building HLFS-based systems.
While this is undoubtedly off-topic, what I really want to see (and continually try to create) is a desktop system with some of these advanced security concepts enabled. The problem seems to be finding the right balance between security and ease-of-use, it's a lot easier to create a server with non-standard access control than an xorg/KDE desktop.
Contributing to this problem (at least in my experience) are the documentation problems. These can occur in many opensource projects but seem to be magnified in security projects. Even with a fair working knowledge of relevant areas, incomplete and esoteric documentation provides a stumbling block for a lot of us.
To me, the whole idea of one distro magically becoming more secure than another is slightly strange - it's not really so much the kernel itself - it's what's ontop of the kernel, the default install, uh, defaults, and the entire chain-of-trust ontop of that. Any production server *should* be competently administered - and locked down fairly tight (e.g. NOT running an nwn dæmon, as a certain webserver I've come across did due to the sysadmin thinking he could get away with it....), and then the only security troubles you'll come up against are those that are totally PEBKAC. (Yes, I know must security problems lie BKAC, but this really does seem to me nothing other than a /. sponsored PR-stunt...)
/" from the man pages....
The flipside of this is linux on the desktop - which is where redhat could earn this title. However, all that really means is making sure wine is b0rken enough with windows viruses, not allowing samba or ssh access from outside the local subnet, and removing all instances of "rm -rf
My UID is prime. Is yours?
Sure you can do it. Samba and Apache just have to be part of the same security domain. Study up, boy.
I, for one, welcome our new Antichrist overlord.
Looks like it's time to trot out this link again:
Jonathan S. Shapiro, Ph.D: Understanding the Windows (and Red Hat) EAL4 Evaluation.
"In the case of CAPP, an EAL4 evaluation tells you everything you need to know. It tells you that Microsoft (Red Hat) spent millions of dollars producing documentation that shows that Windows 2000 (RHEL 5) meets an inadequate set of requirements, and that you can have reasonably strong confidence that this is the case."
Granted, RHEL is being evaluated for LSPP as well, but EAL4 is still weak.
All the comments about OpenBSD are missing the point: Common Criteria isn't about actual security; it's about security documentation. It's also about certain government purchasing requirements. Nothing to see here.
Where I work, it's a Windows/Novell shop. The director doesn't care about security nearly as much as usability. Is that wrong? Hell yes, but that's how it is. Security is our responsibility (not his), and when he's choosing products, he goes for usability. He only recently allowed us to test some SuSE boxes because a) they were endorsed by Novell, and b) he liked YaST. He wanted to understand what we are doing to the boxes. Command line is evil to him, as is anything "open source" or free as in beer (free as in speech means nothing to him)). If it doesn't cost a lot of money and doesn't have an "easy" interface, it's inferior.
I spent a great deal of time trying to get SELinux in FC working, it turns out like most things, the devil is in the details. Here's why:
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/ 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.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Again, it's not secure no matter what you do. If you can scan memory at anytime, you can find keys and such and get what you want. Running at PL0 and PL3 and leaving out the other 2 PLs can allow any code to run in-between PL0 and PL3 and then where will you be. A 4-layer OS is the answer.
Fortunately, my company is going to announce soon with an OS that truly is secure.
Flame away (again).
SELinux is a great idea but really complex to the point of obscurity. I couldn't come up on my own policy rules for SELinux to make Samba run in a more secure manner. I am the first to agree OpenBSD is the king of secure policy but really bites at allowing an administrator to manipulate them. This is where RH comes in and does very well with their push into SELinux. It is sufficiently complex but in most cases the way RH uses SELinux the user never notices.
Ever since they've introduced SELinux in the default install they've claimed it is incomplete but are adding rules every chance they get. And even better, there is nearly transparent to the "uninterested user". There is a seperate SELinux package that merges in every time they update it so my interaction (and the chance for me to break it) is minimized. And I'm constantly surprised by the settings they do work out as well (for instance some of their Samba settings are really good security policy anyway).
Red Hat's support for things like SELinux is stellar but it needs to be better and they are the first admit it needs more work. Isn't this what Open Source is all about?
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.
Dewey, what part of this looks like authorities should be involved?
I think alot of people are really missing the point, but saying "use openbsd" or use "xzy". use can have a secure data server in gov or mil orgs and have secert or top seceret data on if without "trusted" computer and defined and verus security qualifacations. SElinux provides ROLE based access control. this is a good thing, as RH will add alots documentation to selinux and maybe even some tools as well.
-Nex6
-Nex6.blogspot.com
PIE is pretty neat in that it randomizes the memory layout so an attacker executing an attack can't know what memory lays ahead, often making the overflow useless.
I wouldn't go that far. You can do plenty of bad things without knowing the memory layout in advance. Denial of service comes to mind. Not as bad as arbitrary code execution, but still serious.
PIE is not a magic bullet. It is just something to raise the bar a bit.
LedgerSMB: Open source Accounting/ERP
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.
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.
It definitely will not make an insecure application or insecure installation more secure, but it will provide additional protection against those insecure situations.
And the post is modded appropriately as funny since it is a humorous jab at linux security. Besides, I could be off base on this but I suspect that simply installing BSD as your OS will not resolve security issues in the applications you install on top of it, i.e. SQL inject exploits in applications such as PHPBB.
From what I have observed in the #fedora channel on freenode.net most people are oblivious to the existence and operation of selinux and they do not turn it off. However, I have observed people having problems related to selinux when they start utilizing advanced services on their fedora boxes, i.e. apache, named, etc. And in many cases I've seen people offer up the solution of just disabling selinux. This is unfortunate, however, it is not surprising considering the current lack of selinux experience. When possible I've provided some assistance and prevented the disabling of selinux as a solution, but its just a drop in the bucket.
I suspect that in the future there will be some good selinux frontends to assist the masses with configuration. I would not write it off just yet.
burnin
I've read through the article, and I've read through the discussions here. The article really doesn't say that much.
Red Hat is talking about working with NIAP. This means they are going for a Common Criteria rating, which simply means it will be easier for the government to purchase the product for DoD acquisitions.
Does it mean the product is more secure? Only in press releases.
Security consists of two aspects: the functions provided to address threats in the environment (functional), and the confidence that those functions are correctly implemented (assurance). For a given product, the functional and assurance requirements are defined in the Security Target. As the article never mentioned the target, we have no idea what functions are claimed (although we can presume it is likely the set of C2 functions from TCSEC days, but that's unclear). This is important: I've seen products with really useless functions get evaluated, and I've seen ones with a reasonable function set.
Next, is the assurance question. EAL4 was mentioned, which is simply the highest level that can get mutual recognition. It is only moderate security... and again, only provides assurance relative to the functions that are claimed. Assurance is also related to the environment. If this product is for a "benign" environment, then it won't be subjected to strong testing.
This all comes together in the testing, which is relative to the functions and assurance. If there isn't strong vulnerability testing, then you only have relatively simple functional testing. If there is vulnerability testing, this is more in relation to the claimed functions. For example, if the product doesn't claim that it protects against denial of service attacks, then the vulnerability testers don't have the obligation to see if they can create a denial of service condition.
In short, this is a long way of saying: this is a press release, and needs the usual grain of salt. Get the Security Target. Read it. Understand the claimed security. This is true for ANY evaluated product.