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.""
OpenBSD (Score:2, Interesting)
Why don't the security conscious just use OpenBSD [openbsd.org]?
Is this a magnet? (Score:1, Interesting)
Granted, I think Red Hat has a much better head start on MS, but that may partly be due to the amount of market share they command. If they can pull it off, more power to Red Hat!
Yes the NSA does (Score:3, Interesting)
Secure operating systems... (Score:5, Interesting)
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!
Secure desktops (Score:3, Interesting)
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.
Secure and Usefull (Score:1, Interesting)
Summary: RedHat delivers both a secure and a usable Linux distro which is easily supportable and reproducable.
Re:But SELinux SUCKS for enterprise (Score:4, Interesting)
Re:But SELinux SUCKS for enterprise (Score:1, Interesting)
Ignorance is no excuse.
Security vs. Usability (Score:3, Interesting)
One Thing RH Does Do Well... (Score:4, Interesting)
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?
Re:OpenBSD (Score:2, Interesting)
Anyway, I don't believe that my out of dateness really invalidates the rest of my post. The most important point is that trying to implement everything correctly is not really a practical way of making a secure system. This has (historically) been OpenBSD's approach, but it suffers from the issues I raised before. Having better access controls makes it easier to make a secure system given that some of your software will have bugs.
All other things being equal (i.e. implementation, no-exec stacks and heaps, etc), which is better: a kernel that has a all privilege/no privilege model where all software can generally see everything else, or a kernel where software can be given limited amounts of privilege if necessary and unrelated software is isolated from each other, limiting avenues of attack?
I think the work OpenBSD has done is good, and they've made a lot of progess in quality of implementation, secure default configuration, and doing a lot of the stuff that everyone should have been doing years ago. But it seems to me that they've only recently (i.e. past 3 years) figured out that bug fixing isn't enough.
The trusted systems community, on the other hand, has known for a long time (10 years, maybe more) that security through quality of implementation is impractical. I think our methods and markets have just been so niche that nobody knows about us or takes us seriously. And the usability of most trusted OS's stinks (not because it has to, though; that's just how things have turned out at the moment).
Anyway, I'd encourage you to take a look at the docs I mentioned earlier (especially the LX docs on the Argus site; LX is the lightest, most useable system of the bunch). I think you'll see where some of those access control mechanisms would be useful if you give them a chance.
Re:Missed a link :) (Score:5, Interesting)
Knowing my machines are bulletproof is great, and all, but if one of my users is deliberately doing something s/he shouldn't, I want to know about it!
Re:Missed a link :) (Score:3, Interesting)
Re:OpenBSD (Score:3, Interesting)
In addition to "trying to do things correctly" (and succeeding at it, btw), the OpenBSD team has had an excellent randomization algorithm for TCP/IP sequence numbers for years, has implemented the W^X flag, is now randomizing malloc addresses, has had OS support of cryptology for years, has practiced proactive instead of reactive security, etc, etc, etc. The list is rather long. I'm not an OpenBSD advocate, I don't pretend to be one, I don't want to be one. I just use OpenBSD in my security applications.
Maybe it would be helpful if you spent more time understanding what the OpenBSD team is really doing, instead of describing your incorrect perceptions of what you think they are doing.
selinux effectiveness (Score:3, Interesting)
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
Meaning of "Secure" (Score:2, Interesting)
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.