Posted
by
ScuttleMonkeyon Wednesday September 28, 2005 @01:38PM
from the still-need-proper-configuration dept.

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.""

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.

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.

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.

``I don't need SELinux on my notebook or my desktop and I don't need it in my 20 man organization''

Ah? So you like those worms, backdoors, and rootkits?

Remember, there was a time that DOS users "didn't need virus scanners". There was a time when having services running by default was user friendly, "not a security risk". There was a time when Windows users could use their systems to get work done, rather than spending their time cleaning off the spyware. There's a moral to this story.

SELinux does not make anything more secure. [...]
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.

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.

SE Linux is a mess, at least if you're one of the 60% odd of interent sites who use apache. Yes, apache is a complicated daemon, but Trusted Solaris had it right - foo.com has access to this part of the filesystem, bar.com has access to this. If you're using virtual hosting or user directories, especially with dynamic content, having apache run as www for everyone was pretty lousy security. But SE Linux hasn't moved very far from this, while adding layers of complexity to protect www from the rest of the fi

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.

``The OpenBSD approach is to raise the quality level of the code to eliminate flaws in the operating environment.... 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.''

Interesting. I've been playing with OpenBSD at home for a few years, long enough to encounter the well-known 'challenging' areas (upgrades. And coping with two separate toolchains is fun:) Meanwhile I've been given some Fedora Core 4 machines to admin at work. I knew RH had the SELinux extensions but never used them. Where to start? I ended up with the FC3 SELinux FAQ at redhat.com, which makes it clear that it needs a fair amount of care and attention, especially during the time I call "the coming of the great admin learning curve" - well, this admin anyway:) A thought has struck me: has anyone got past the initial setup, false-positive squishing and crossing off log entries as you fix or reconfig stuff, to a stable machine, then either (a) first discovered attacks (successful or not) via SELinux alerting mechanisms, or (b) got useful, or even just interesting, evidence of naughty activity via SEL logs, etc?

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!

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?

I couldn't come up on my own policy rules for SELinux to make Samba run in a more secure manner.

You'll never come up with a policy that makes samba significantly more secure, unless Microsoft provides clients that can use a secure implementation of the NetBIOS/NetBEUI/SMB/CIFS/whatever-they-call-it-thi s-week protocol.

That's not a failing of SELinux, nor of OpenBSD, or even of Samba itself. Samba's a tool for communicating with systems through an insecure protocol.

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 applicatio

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.

You are indeed wrong. OpenBSD includes a number of systems which make buggy code more secure. Some examples:

W^X protection - no memory page is both writable and executable at the same time. This doesn't affect properly written JIT compilers - they make the page writable, modify it, then make it executable.

.rodata segment - An additional segment in the binary for storing data (separating code and constants). This enables the constants in a piece of code to be mapped into non-executable memory, preventing it being used by exploits.

Guard pages - any large (page-sized, or over) malloc() allocation gets an extra page allocated before and after it. These pages are marked as no read, write or execute, so any attempt to access them (going over a buffer, for example), causes a segmentation violation.

Randomised malloc() and mmap(). The base address of every new memory allocation is random. This prevents attacks based on deterministic runs of the program allowing an attacker to know (or guess) where a particular memory value will be.

Propolice provides incredible stack protection (and has forced OpenBSD to stick to a slightly older version of gcc, since the gcc people don't believe in security and won't integrate their patches). It makes stack-smashing attacks almost impossible using randomly spaced stack frames and canary values - the canary is even used on SPARC64, which uses rotating register windows for the top 7 stack frames.
There are others that have slipped my mind while writing this. I went to a talk at Linux 2005 by one of the OpenBSD guys - he talked very quickly (and entertainingly) for his entire session, and still didn't have time to cover all of the mechanisms.

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.

I must've missed the part in the article that was something other than PR. A little light on details; but this is only about getting certified under a certain configuration. I doubt RH will ship Enterprise with this config as the default as it is a bit less than user/admin friendly.
Having said that: Good for them.

These technologies seem to about the security model of Red Hat Linux. But security and security models are not the same thing. Guess what? Windows XP has a great security model, but buggy implementation and poor default policies made it insecure. OpenBSD has a primitive security model, but careful implementation and well chosen default policies have made it very secure.

Adopting stuff like SELinux will make Red Hat Linux closer to Windows in security model. Red Hat moved to good default policies faster tha

Sure they can- they can review and check the code in their kernels, and not accept patches that are risky. Rarely do any of the big distros ship unmodified kernels anyway- they all add patches of some sort or another.

If Red Hat are genuinely aiming to provide a platform capable of mixing restricted, secret and TS material on the same system then good luck to them. But I don't see any real users with material genuinely warranting those classifications being ready to trust such a system until a long time and a vast amount of validation work have been done.

If Red Hat are genuinely aiming to provide a platform capable of mixing restricted, secret and TS material on the same system then good luck to them. But I don't see any real users with material genuinely warranting those classifications being ready to trust such a system until a long time and a vast amount of validation work have been done.

Some really clueless moderator modded you down as flamebait, go figure. I any case, the Linux kernel has had about 20-30 of local root exploits in the last year, and clearly the Linux kernel leaves something to be desired in this regard. It's also understandable that this happens due to the huge amount of new code, and the focus on performance (but not stability).

OpenBSD, from what I've heard, is good, but most of its security is based upon correct implementation. This is good, but the OpenBSD team can only audit and control the base system, meaning that applications and libraries added to the system can often degrade the security of the system as a whole.

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, and2) 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:

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]

Sorry if I was misinformative. It feels like privilege separation came out yesterday, but I think you're right: it's been about 3-5 years now, right?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 easi

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.

In addition to "trying to do things correctly" (and succeeding at it, btw),

Because SMP support on OpenBSD is in its infancy and doesn't scale well beyond 2 processors. Because they don't support hyper-threading worth a darn. RAID and LVM support are also being redone and very immature at this time. All these issues are of critical importances on server systems.

You're not particulary informed, it seems.
The RAID support in OpenBSD is very good, and what they've added is a unified RAID management system that will be expanded to more cards in the future. There is no LVM support in OpenBSD, thus it can't be redone. Yo seem to have heard that SMP support in OpenBSD is fairly recen,t kudos to you.

A critical importance of is, of course, stability and relability and then I don't want to be hold hostage to some binary-only shoddy RAID managment software running on Linux

You flamed the other guy for being "not particularly informed" and then you post "I don't want to be hold hostage to some binary-only shoddy RAID managment software running on Linux"?I've been running completely open-source soft RAID for years on Red Hat linux. My backup server, which uses the same basic idea as dirvish [dirvish.org], uses a couple of terabytes of RAID10. There are even multiple RAID implementations freely available, although you are typically restricted by your choice of kernels.

OpenBSD didn't support in-place package upgrades until 3.7; you had to make a list of installed packages, delete them, then install the new versions. {Free,Net}BSD made ports/package upgrades so easy that maintaining OpenBSD seemed like a chore by comparison.

You're still told not to make your own kernel. Every other Free Unix on the planet is happy to tell you how to compile your own locally-customized kernel, but the OpenBSD guys make it sound like only 1337 k1dd13s and other jackasses wo

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 e

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

All sorts of stuff actually. Their mission is twofold; in addition to breaking the bad guys codes or elsewise compromising their communications, they are also tasked with protecting the good guys communications from being compromised. Now it's important to remember that "good guys" and "bad guys" here is as defined by the US Government, but I for one agree with them at least ocasionally. In any case, if they have thought up some super secret tricky way to get around your security, I wouldn't expect them

Call me paranoid. Actually, it's not even in the least paranoid. But I just don't want code written by the government on my computer. Not that I'm in the "Enterprise" market, anyway. *shiver* There's just too much that could go wrong...especially if it became a long-standing policy.

The book Animal Farm was about animals on a farm that resented being under the control of humans. Their motto was something to the effect of "4 legs good, 2 legs bad" meaning that everyone with 2 legs was bad. Over the course of the book, the pigs started to take over the leadership role, championing the causes of the other animals and ultimately displacing the humans. For a period of time all was well, but by the end of the book the pigs had started walking on 2 legs and were no better than the original, human leadership team.

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.

I think you are mistaken. It is entirely probable that RedHat the company will partner up with lots of big businesses. Big businesses, however, want a commodity OS, competitive advantages, and for that matter, open source at this point. Having been burned by MS for so long, many companies at the heart of the Linux community are unlikely to swiftly move to closed formats, APIs, code, etc. Even assuming RedHat did exactly that, introducing formats and closed source code as much as possible, they are still working on a base that is GPL and that they cannot close and still sell. That means there is nothing stopping others from modifying that code or even redistributing it. RedHat would basically have to write their own OS from scratch or based upon BSD licensed code in order to get us close to the situation we have with MS. Even were they to do that, we'd still be several steps ahead for compatibility and security from where we are now with Windows.

To summarize, sure RedHat can become "evil" but that does not stop Linux, and RedHat has no way to "take over" Linux since they don't own it. I'm just not too worried, they have a long hard road ahead to become MS, and they will need a new OS to do it.

If you want to argue that RedHat has turned its back on the community, or jumped in bed with big business, or whatever, go right ahead. But it simply isn't possible for any Linux distributor to "become Microsoft", because unlike Microsoft, anybody who can obtain a copy of Distro X can legally rebrand, recompile, and sell it as Distro Y. Somebody running Distro Z can go through Distro X, figure out any new features, and bring those features to Distro Z.

RedHat can't do a thing to stop RH-based distros like CentOS and White Box. The GPL ensures that, while one distro might dominate the Linux landscape, nobody will ever have a lock on Linux itself. Linux World Domination would mean that nobody can dominate.

So please, elaborate your reasoning. What is RedHat doing that scares you?

But it simply isn't possible for any Linux distributor to "become Microsoft", because unlike Microsoft, anybody who can obtain a copy of Distro X can legally rebrand, recompile, and sell it as Distro Y. Somebody running Distro Z can go through Distro X, figure out any new features, and bring those features to Distro Z.

And this is very important because it means that, in order to keep my business, Distro X must continue to represent a good choice. They must offer reliability, trustworthiness, and good service. Why do people continue to buy Redhat even as CentOS is released? Because they trust Redhat and like Redhat's support.

Open source vendors simply won't make any money unless their customers are happy.

No they didn't. They wrote to CentOS to inform them that they were using Red Hat's trademark in a way that Red Hat felt was inappropriate. The letter also stated that people were not allowed to use their trademark in that matter without "express agreement." What CentOS had to opportunity to do was call or write the lawyer, state their side of things, and work out an agreement that would work for both parties. Working out such an agreement w

Umm... Red Hat has been the best thing the community has going for it. Red Hat is the only reason the kernel is of enterprise quality. Red Hat is the only reason the kernel has any kind of serious testing going on behind the scense. Red Hat has some defensive patents, but they come attached with an unrevokable allowance of OSS projects to use them in any way. Red Hat contributes more code to the kernel than anyone else, they also supply most of the security upates for it. They bought and gave us Cygwin, Fed

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!

And, as for RedHat becoming the next Microsoft - journalists have asked this rhetorical question for quite a while now (and redhat is still a niche player). My personal opinion is that there's not gonna be a next Microsoft (as in a company that makes billions out of selling proprietary operating systems). I believe that the OS market will be commoditized to the point that there is not gonna be another mammoth.

Furthermore, keep in mind that most of the code behind linux is under either GPL or LGPL, which m

a very viable way for Microsoft to keep Linux as weaker competitor.1. In the corporate world where support is more valuable than the software in some cases, there is *not* a long list of viable Linux-based companies. I don't think Novell's going to dismantle Red Hat either.

2. The approach MS will likely take is to capture as many of the Linux dollars as they can. They know support is Linux's weakness and they can provide that. So, Microsoft bundles OSS application support to it's richest customers. Mi

Interestingly enough, this same pattern can be seen in some large IRC channels. Particulary tech channels. I remember chatting in #linux. The regulars/ops would get extremely intolerant of newbies and try to censor a lot of things. Eventually, a group would break of to start a new #linux* channel to be free from the "op-pression". And within months, that channel would be just as bad as the original. And the cycle would continue...

Look at how much they suffered when they discontinued Red Hat Linux in favor of Fedora. The Linux marketplace is much more competitive than Microsoft's market ever has been. We are not talking about one DOS clone here. We are talking about at least 9 commercial and noncommercial entities which directly compete with Red Hat in this area. Yet due to FOSS, they all share many of their innovations between eachother.

Cheer all you want for the little guy, but a lot of CIOs (and PHBs in general) don't trust anyone BUT "The Man". Redhat being "The Man" represents greater market penetration for Linux, as well as someone else in the "community" who is generating revenue from Linux and who has a financial interest in improving the code and marketing Linux.

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.

I choose a *nix based on the package management, generally. Ports just doesn't cut it for me on a workstation. Ports is OK for servers where you install and let it run for years (I'd prefer Debian though).

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.

Wrong!

OpenBSD can run all FOSS software avaliable for Linux (as long as the source doesn't use too many Linuxisms; e.g., code that extensively uses the Linux kernel won't compile). As long as the source uses standard Unix libraries, standard X libraries, standard QT/GTK toolkits, then it should run fine on OpenBSD.

Redhat is the target OS of most corporations (as I pointed out), this is the advantage that Redhat has over OpenBSD. Any worthwhile features that this develops will eventually trickle down to the niche distros such as slackware and gentoo; so this initiative is a Good Thing.

As far as stealing users from windows; So Freaking What? The important thing is that people discover there are alternatives to using Windows and hopefully also discover the advantages of Free Software along the way.

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!

It's a goddamn PITA to download all that though, I have to admit. While it isn't make-break kind of thing determining if I like a distro or not, I do much like offering the distro in a 1-CD format (eg, Ubuntu) and just using repositories to fill out my software.But then again, I'm not an average user, and require special tools that are often not on the disk anyways, and if they are, are frequently not the version I want.

That's not to say that packing a DVD that includes a bunch of applications is bad, but

I agree completely. I've been asking for some of these features with good defaults and a user friendly configuration on a usable desktop for years. Right now, only the most security conscious are looking to these systems, but as security tightens in general this type of system will become more and more needed. I still have my doubts that this sort of system will gain any popularity until newer version of Windows manage to take significant market share and remove some of the lowest hanging fruit for malware

Trustix Secure Linux [trustix.org] 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.

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.

That's what you might think. But you're not taking into account the ninja hackers who boot up your PC while you sleep and install all sorts of nasty virii onto your machine. And they bring their own Enter keys!

It was a basically flawed design from the start, and failed to withstand an obvious hazard that would not have sunk one of Brunel's much earlier iron ships. So it's quite different from Windows 2000 which is not a basically flawed design...er, what am I saying?

running fast in the fog so that one rams a freakin' iceberg isn't really an obvious hazard. The Titanic's sister ship served for years afterward with no problems. The design criteria was to survive x partitions breached, and they did x + y and it sank. It failed fully complying with design specs, had ISO 9xxx existed they could even have proudly put the big ISO 9xxx sticker on the (brittle high-sulfur steel) side, it was Quality Ship by todays standards!

I think this is a bad idea. There are always tradeoffs between security and functionality, so a most secure linux will always be niche. There's a place for such distros, and the great thing about linux is that different distros can be made to suit anyone, but a distro trying to be mainstream like red hat should not aim to be the best at any one thing, because that means neglecting other important things.

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 sec

"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/ [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.

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.

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.

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

Security is not a product. It is a process. You cannot talk about the "most secure OS." You can only talk about two tangental issues:1) The most securable OS and2) The most secure OS in the default install.There will always be some MS Windows boxes that are more secure than some OpenBSD boxes if only because someone thought that "Cool OpenBSD is really secure, man. So I just installed Sendmail on it.... I don't have to worry about security, do I?" while there are a few Windows admins who take securit

a proper ACL implementation a-la Windows (don't laugh - they have a really good one)

Like hell they do. If there's a simple way to tell it "give (group) full control over this directory and everything underneath it", and not have it silently fail on certain branches, then please for God's sake tell me what it is?