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

54 of 262 comments (clear)

  1. Missed a link :) by grub · · Score: 5, Funny

    The article left out a hyperlink, corrected here :
    Red Hat Enterprise Linux will join an exclusive community of trusted operating systems that have achieved this level of security
    --
    Trolling is a art,
    1. Re:Missed a link :) by TheRaven64 · · Score: 3, Insightful

      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
    2. Re:Missed a link :) by Homology · · Score: 3, 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/ 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.

    3. Re:Missed a link :) by Anonymous Coward · · Score: 4, Insightful

      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.

    4. Re:Missed a link :) by andyross · · Score: 5, Insightful
      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.

    5. Re:Missed a link :) by duffbeer703 · · Score: 4, Insightful

      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
    6. Re:Missed a link :) by kosmosik · · Score: 2, Informative

      RedHat/Fedora already do have ExecShield, which is similar to Pax:

      http://www.redhat.com/magazine/009jul05/features/e xecshield/

    7. Re:Missed a link :) by RAMMS+EIN · · Score: 3, Informative

      ``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.''

      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.

      --
      Please correct me if I got my facts wrong.
    8. Re:Missed a link :) by Cally · · Score: 4, Interesting
      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!

      --
      "None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
    9. Re:Missed a link :) by pyrotic · · Score: 2, Interesting

      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 filesystem. Nice if you have one site per server, but if you have multiple sites all running as www, with different user scripts all having write access to the same places, SE Linux doesn't solve your problem at all.

  2. OpenBSD by biryokumaru · · Score: 2, Interesting

    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!
    1. Re:OpenBSD by Anonymous Coward · · Score: 4, Informative

      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, 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/linu x-privs/kernel-2.4/capfaq-0.2.txt

      Trusted BSD:
      http://www.trustedbsd.org/docs.html

      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/

      Trusted Computer Solutions (mentioned in the article):
      http://www.trustedcs.com/index.html

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

    2. Re:OpenBSD by QuietLagoon · · Score: 2, Informative
      Should have been modded as mis-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".

    3. Re:OpenBSD by Anonymous Coward · · Score: 2, Interesting

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

    4. Re:OpenBSD by QuietLagoon · · 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.

      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.

    5. Re:OpenBSD by mcrbids · · Score: 2, Insightful

      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.
    6. Re:OpenBSD by dmiller · · Score: 2, Insightful

      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.

  3. RedHat poised to become the next Microsoft by kianu7 · · Score: 3, Insightful
    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.

    1. Re:RedHat poised to become the next Microsoft by 99BottlesOfBeerInMyF · · Score: 5, Insightful

      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.

    2. Re:RedHat poised to become the next Microsoft by An+Onerous+Coward · · Score: 4, Insightful

      I don't understand why people keep trying to make that comparison.

      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?

      --

      You want the truthiness? You can't handle the truthiness!

    3. Re:RedHat poised to become the next Microsoft by LnxAddct · · Score: 2, Insightful

      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, Fedora Directory Server, GFS (Global File System) and many other things. They maintain GCC and libc. They created GCJ so we can run java applications natively (its still under heavy development but compiles Eclipse and OpenOffice fine). They have done many other things for the community as well, but I won't go on as I've already done that in another post in this thread. Everything they release is GPLed, I could only hope that Red Hat eventually knocks Microsoft out of its position. Its not like they can get to that point and then undo their GPLed code... and by that time they will have invested billions in that GPL code, they aren't just going to turn their backs on it. They are currently a mulitbillion dollar company (I believe their market cap is around 3 billion) and they have yet to turn on the community. I can only hope that companies like Red Hat and Google dominate the future, it'd be in our best interest.
      Regards,
      Steve

    4. Re:RedHat poised to become the next Microsoft by nine-times · · Score: 3, Insightful
      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.

    5. Re:RedHat poised to become the next Microsoft by Matt+Perry · · Score: 2, Informative
      Just one example - they threatened CentOS with legal action.
      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 wouldn't have cost more than a phone call and several hours of time. I've worked out several such agreements myself in the past (although not with Red Hat or anything doing with open source). It's not a big deal. What CentOS decided to do was remove references to Red Hat from their site. That's their prerogative.

      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.

      --
      Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
  4. and this is why... by mrbobjoe · · Score: 3, Funny

    ITO is running a story...
    ...and probably running it as root, too, the stupid bastards.

  5. Why not OpenBSD. by RLiegh · · Score: 3, Insightful

    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.

    1. Re:Why not OpenBSD. by Mr.+Underbridge · · Score: 4, Funny

      So that's why OpenBSD is so secure - nothing runs on it. ;)

    2. Re:Why not OpenBSD. by linguae · · Score: 2, Insightful
      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.

      OpenBSD also has a Linux binary compatibility layer, too, meaning that it can run Linux-only closed-source binary software such as the Java JDK, Oracle, Mathematica, StarOffice, etc. OpenBSD can also run FreeBSD applications and even SCO Unix applications.

      So, OpenBSD has just the same variety in applications that Linux does. Try again, troll.

  6. Yes the NSA does by jhines · · Score: 2, Interesting

    Yes they do http://www.nsa.gov/selinux/info/faq.cfm#I2, the mentioned security enhancements are more like ACL's and policies.

  7. Re:the NSA? by ettlz · · Score: 4, Funny
    I didn't realize that ANYTHING they did was "open".

    Cavity searches.

  8. Re:Is this a magnet? by LnxAddct · · Score: 5, Informative

    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

  9. In other news by $RANDOMLUSER · · Score: 4, Funny

    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
  10. Secure operating systems... by Anonymous Coward · · Score: 5, Interesting

    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!

  11. Trustix by Rinisari · · Score: 4, Informative

    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.

  12. I have the most secutiry... by OctoberSky · · Score: 2, Funny

    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.

    1. Re:I have the most secutiry... by pharwell · · Score: 2, Funny

      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!

      --
      I quote others only in order the better to express myself. -- Michel de Montaigne
  13. Holy crap!!! by Anonymous Coward · · Score: 2, Funny

    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!

  14. History by eno2001 · · Score: 3, Insightful

    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
  15. But can we trust them? by ValuJet · · Score: 4, Funny
    I like the idea of trusted computing. It gives me this warm fuzzy feeling all the way down to my toes. Sure security is an ok word, but I like how the word trust makes me feel even more.

  16. Secure desktops by shudde · · 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.

  17. I really don't want to troll, but... by Landak · · Score: 2, Insightful

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

    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 /" from the man pages....

    --
    My UID is prime. Is yours?
  18. Re:But SELinux SUCKS for enterprise by sabat · · Score: 4, Interesting

    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.
  19. Common Criteria evaluation is mostly worthless by Wesley+Felter · · Score: 3, Insightful

    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.

  20. Security vs. Usability by Anonymous Coward · · Score: 3, Interesting

    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.

  21. The SELinux Devil... by mpapet · · Score: 2, Informative

    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
  22. Re:But SELinux SUCKS for enterprise by emurphy42 · · Score: 2, Informative
    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?
  23. Bah! by supradave · · Score: 2, Informative

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

  24. One Thing RH Does Do Well... by EXTomar · · Score: 3, Interesting

    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?

  25. Because everything but the base system is painful by Just+Some+Guy · · Score: 2, Informative
    Because:

    1. 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.
    2. 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 would want to do this.
    3. Their packages are ancient. I don't want to install KDE 3.3.2 (came out November 2004) on an OS release that came out in May 2005. I don't expect to get packages that came out yesterday from a release that came out 5 months ago (even if {Free,Net}BSD and most Linuxes manage it), but I'd like to at least have the versions that were current when that release was made.

    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?
  26. missing the point by Nex6 · · Score: 2, Informative

    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

  27. Re:Is this a magnet? by einhverfr · · Score: 2, Insightful

    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
  28. Re: I didn't try hard enough so it sucks by oddityfds · · 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.

    Run:

    # up2date --install (or yum install) selinux-policy-targeted-sources
    # cd /etc/selinux/targeted/src/policy
    # 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.

  29. selinux effectiveness by burnin1965 · · Score: 2, Interesting
    ...SELinux does not make anything more secure...

    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.

    ...it's sufficiently complicated that most people are just going to turn it off...

    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
    1. Re:selinux effectiveness by TheRaven64 · · Score: 3, Informative
      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 am TheRaven on Soylent News
  30. Meaning of "Secure" by hwyguy2 · · Score: 2, Interesting

    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.