Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Software Linux

Red Hat Boosts SELinux With RHEL 5 175

E. Stride writes "Many IT managers find Security Enhanced Linux, or SELinux, to be wildly complex. The mandatory access controls originally developed by the NSA have developed a reputation for being too complicated to deal with, and many IT shops simply turn the feature off. However, Red Hat's Dan Walsh says it's the only way to ensure 100% protection in the data center."
This discussion has been archived. No new comments can be posted.

Red Hat Boosts SELinux With RHEL 5

Comments Filter:
  • by rucs_hack ( 784150 ) on Tuesday June 05, 2007 @09:11PM (#19405711)
    SElinux certainly sounds interesting. How relevant is it for the normal user?

    Is it better for my personal linux box to have this or is Iptables enough?
  • 100% Secure (Score:5, Interesting)

    by whterbt ( 211035 ) <m6d07iv02@sneakemail.com> on Tuesday June 05, 2007 @09:15PM (#19405737)

    Ignoring for now that nowhere in the article does he claim that SELinux provides or is required for "100% security", there's no such damn thing. Unless you pull out the power cord, of course.

    Yes, we disable SELinux at our shop. As the article mentions, it's a pain in the ass, and the tools to manage it are not mature enough. If all you have is RHEL, and you have nothing else to do, you can look at configuring it. If you have a bunch of corporate mucky-mucks breathing down your neck, and you have to get the latest version of GnuWhatever compiled for 5 different OSs, there's no time to deal with this nonsense.

    SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability, and right now, SELinux is just above yanking the power cord.

  • by Cozminsky ( 452030 ) on Tuesday June 05, 2007 @09:20PM (#19405767) Homepage
    Although SELinux is a step in the right direction it's still basically a system of ACLs. It still suffers from the problem of the confused deputy [upenn.edu]. I think proponents of object-capability based security are correct in their thinking. Some interesting stuff going on in this respect is the E programing language [erights.org].
  • SELinux is a problem (Score:2, Interesting)

    by Henry V .009 ( 518000 ) on Tuesday June 05, 2007 @09:34PM (#19405829) Journal
    I've never run an RHEL server for more than 24 hours without experiencing an SELinux problem. Every new release, the same story.

    Just the other day, I tried to install "rt" on a brand new RHEL 5 box for a demo (we're looking into new ticket systems). I found that "yum install mysql-server" hung forever. Same with the apache install. It turns out the SELinux thinks that useradd being run by the mysql rpm (to add user "mysql") was trying to attack /dev/random. So SELinux blocks reads to /dev/random and useradd hangs which makes yum hang. And yum is one process that I sure don't want to kill.

    This wasn't a hacked up RHEL box or anything. I had installed it that morning.

    There were suggested fixes in my logs, but they did not work. My solution? Disable SELinux. It's just not ready for prime-time. Or production environments.
  • by liftphreaker ( 972707 ) on Tuesday June 05, 2007 @09:51PM (#19405935)
    Whatever Redhat says, the fact remains that SELinux is an incredibly complex, and incredibly undocumented (or under-documented) piece of software. It took me two months to really understand how it worked and what exactly to configure when I needed to fine-tune access rights and permissions on our servers. That is a nightmare I wouldn't wish on anyone.

    Redhat is not going to get much traction from this unless there is a very easy to use tool (preferably with GUI) to configure and customize SELinux, out of the box. The default tools on RHEL allow a few options during install time, but it is truly primitive.

    There really doesn't need to be this huge love/hate relationship with SELinux, in fact why not just throw it out and use something far simpler and neater? There are several options out there. Off the top of my head I can think of GRSEC : http://www.grsecurity.net/ [grsecurity.net]

    We've been using this on two of our server farms and it's been doing a superb job, and it is very very easy to customize compared to the SElinux nightmare.
  • Re:anecdotes... (Score:3, Interesting)

    by chill ( 34294 ) on Tuesday June 05, 2007 @11:53PM (#19406677) Journal
    The problem you and the grandparent have is not grokking what RBAC and MAC are and how the traditional Unix/Linux root == God method of security is fundamentally flawed.

    SELinux makes sure things that are set up don't get arbitrarily changed. It isn't prescient to know that YOU have proper authority to make those changes. You have to tell it that.

    So, with SELinux you have one more step when you make substantive changes. Tell SELinux about it.

    Simply moving folders or files around as root and modifying program config files is NOT enough. What the hell is the difference between YOU doing it and a HACKER doing it? SELinux doesn't know. Hell, things like moving my Apache docroot around is something I'd really want to have secured.

    SELinux (and Solaris 10) try to fix that by implementing RBAC, MAC and Type Enforcement. http://csrc.nist.gov/rbac/rbac-faq.html [nist.gov]
  • Re:100%? (Score:3, Interesting)

    by arivanov ( 12034 ) on Wednesday June 06, 2007 @07:55AM (#19409109) Homepage
    Yep, been there, seen that. I have seen SEL on fedora (4) in permissive mode still breaking an app and had it fixed by turning the damn thing off (it did work properly on Debian 4.0 though). The app was using tty functions from a web-server CGI context which is a requirement for working expect scripts.

    As far as your comment on error codes and 'Permission denied by MAC policy', quite a few (if not most) of app developers do not handle all possible error codes returned by the OS and do not have a "catch-all" clause when handling errors. So returning a "new and wonderfull" error code is actually likely to cause more mayhem, than returning one of the "well known" error codes like -EACCES. I would rather have the actual error code configurable on a per-item basis (dunno if SEL can do that as I have not yet committed to the several days necessary to learn its deep internals).
  • by illumin8 ( 148082 ) on Wednesday June 06, 2007 @10:59AM (#19410865) Journal

    It can save a system from being compromised due to other services which are either weaker, or poorly configured. Taking some time to get SELinux working properly in ones production environment (if that system is important) is more than worth the time it takes to read up on it. Being a lazy sys admin rarely pays off in the long run.
    I agree that SELinux is a good idea, but how do we get vendors to "play nicely" with it? I'm a Linux sysadmin working on a lot of Oracle database servers. Oracle says I have to have SELinux turned off, and in our experience, Oracle won't even install or run with SELinux enabled. I would love to be able to turn SELinux on but Oracle says I can't. Is there any hope for those of us that run commercial apps on Linux and want to see better security?

"If it ain't broke, don't fix it." - Bert Lantz

Working...