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

7 of 262 comments (clear)

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

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

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

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

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