Slashdot Mirror
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.""
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.
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.
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.
I am TheRaven on Soylent News
Except 'most people' and 'sufficiently large government organizations and corporations' are not interchangeable. The NSA or FBI doesn't look at the complexity of SELinux and say decide they are gonna turn it off for that reason. I don't need SELinux on my notebook or my desktop and I don't need it in my 20 man organization, so I turn it off. SELinux isn't designed for me or my organization or my desktop or a good majority of computers out there. But for what it is designed for it does it well.
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
Um, the SE linux configuration shipped with Fedora is on by default, does not create a significant performance hit, and is simple enough that most users (those who aren't making fundamental changes to the installed daemon processes, basically) don't even know it's turned on.
This is mostly a defensive flame. SELinux clearly is useful as a security tool. It provides MAC features that you simply can't get with traditional unix security model. Now, clearly, this kind of change in worldview brings complexity. And lots of installations, even secure ones, don't necessarily need it or want it. And early Fedora (FC2 prereleases, I think) implementations were far too restrictive, and cause much confusion and flamage. I have it turned off on my laptop, for example.
But to baldly claim that "SELinks does not make anything more secure" is just silly.
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?
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.
You're missing the point -- SELinux doesn't make software secure -- it allows you to define secure behavior.
The OpenBSD approach is to raise the quality level of the code to eliminate flaws in the operating environment. That's great -- except not every software development process is shipping flawless software and not every security problem is a result of bugs in software. If Apache or a database or any other application running on BSD has a flaw or is misconfigured, the OS isn't going to protect you or your data.
The SELinux approach gives the operating system control over what is happening on the system. If a hacker or worm compromises an application, and tries to do something that the application is not permitted to do, those actions can be blocked and audited & the impact of flaws or misconfigurations in software can be contained.
SELinux or Trusted Solaris aren't competitors to OpenBSD at all -- they are really in different niches entirely.
Conformity is the jailer of freedom and enemy of growth. -JFK
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
Why do you never have mod points when you need them!
Redhat has been gathering collecting various kernel enhancements for security, and I think creating clear blue water (if you'll forgive the pun) from vendors who make more marketing fuss about far less work.
Whilst I agree that SELinux is too complex for most people, these kinds of security guarantees aren't about "most people", or "most systems", the question is whether basing Linux security on such a system will make the basic system harder to maintain, and I don't think it will. The complexity is largely in using SELinux effectively, not in the underlying systems or concepts.
Having this in the kernel, means Linux has more scope for tightening security. I'm sure over time a lot of this will be utilised, as the attacks get more sophisticated, and the number of installed servers increases.
And to take a leaf from another company's book, nothing like having government security certifications on the marketing literature, even if we know that those sort of stamps mean "it can be secured better with work", not "it is more secure".
Why don't the security conscious just use OpenBSD?
Two words: failing gracefully.
The OpenBSD approach to security boils down to: "Never, ever make a mistake". They've spent untold thousands of man-hours looking for anything that might ever be a mistake. And, towards this end, they've done an incredible job, and have an excellent track record that they can rightly brag about.
But for one thing: mistakes happen. What happens when you write a stoopid CGI and forget to escape a parameter, allowing a blackhat to execute a shell?
Suddenly, OpenBSD or not, you have a real, live, bonafide security hole. In years of administration I've done, EVERY SINGLE SECURITY HOLE exploited on any of the numerous Linux systems I administer of recent were ALL CASES directly a result of a client installing/using software for their websites that was insecure. (3 such incidents in the past 3 years, 2 of them being website defacements) And, I can't just say "Well, let's not allow for shell scripting" because many customers use tools that require this capability.
The approach of SELinux is to acknowledge that mistakes are made, and the starting assumption is that the above mentioned security hole is ALREADY EXPLOITED and a real, live, bad guy already has gotten thru such a security hole.
Now, how do you limit the damage? It's either
1) Never, ever make a mistake - if you do, you are so, utterly screwed!
2) How do you prevent common mistakes from screwing you?
I choose the latter, thank you.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
You are misinformed, trolling or both. Most of OpenBSD's efforts in recent years have been directed at proactive security. OpenBSD was the first operating system to add ProPolice to its compiler, the first to implement address space randomisation, the first to add privilege separation to every daemon that needs privilege.
The result of this is that a security hole is either a) not exploitable to begin with, b) incredibly difficult to exploit, or c) not very productive even if it is exploited. All your caps-lock-on ranting misses this entirely.
I doubt that you want to educate yourself rather than ranting, but other people might be interested in Theo's paper on all this.
In addition to good, audited code and these proactive measures, OpenBSD includes systrace, which can enforce mandatory policy on application basis. It doesn't do everything that SELinux does, but it is far, far easier to use.