Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Red Hat Boosts SELinux With RHEL 5 175

Posted by kdawson from the reducing-false-alarms dept.
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 More

Red Hat Boosts SELinux With RHEL 5

Comments Filter:

  • 100%? (Score:5, Informative)

    by mkro ( 644055 ) on Tuesday June 05, 2007 @09:09PM (#19405693)
    There will never be a 100% protection. A good GUI with a wizard, like with SUSE's AppArmor [opensuse.org], will help a lot of people from falling between the "naah, it broke something on my webserver, turning it off" and "I'll dedicate the two next months of my life to learn SELinux" chairs.

    • Re:100%? (Score:5, Informative)

      by weapon ( 783054 ) on Tuesday June 05, 2007 @09:21PM (#19405769)
      I run fedora and on *many* message boards I see the first trouble shooting idea is to turn off SELinux. What most people forget is that you can set SELinux to be permissive, so it is still turned on, and it lets you know when applications would be doing something that would be prevented. I think changing to permissive mode SELinux is more useful than turning it off as it lets you know what applications are misbehaving. I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies.

      The main disadvantage of AppArmor is that it relies on file paths, not the inodes. All you need to do is be able to create a hard link in the right directory to get around it.

      • Re: (Score:3, Informative)

        by ryanov ( 193048 )
        I agree. This REALLY bothers me from a Sysadmin chair. It's clear that that feature was placed there in order to help you secure your system -- turning it off ought to be grounds for a reprimand from above. You wouldn't leave telnet open to the world in this day and age, so why would you turn off SELinux on a system that used it? At the very least, assigning files to the same context that contains the privileges that you need is something that does not take months to configure, but makes many of the problem
        • It's clear that that feature was placed there in order to help you secure your system -- turning it off ought to be grounds for a reprimand from above. You wouldn't leave telnet open to the world in this day and age, so why would you turn off SELinux on a system that used it?

          Of course you wouldn't unless your manager, out of fear and ignorance, forces you to disable it as step one following installation. This is the same manager that has root access which I must constantly go behind to fix things he's mes

      • Re:100%? (Score:5, Informative)

        by Anonymous Coward on Tuesday June 05, 2007 @11:16PM (#19406485)
        Permissive mode is only useful for policy development. The kernel does not enforce the security policy in permissive mode so it is no more secure than turning it off.

        Enforcing mode = Security policy decisions are enforced, policy violations are logged.
        Permissive mode = Security policy decisions are not enforced, policy violations are logged.
        Disabled = Security policy decisions are not computed.

        • Re: (Score:3, Informative)

          by ryanov ( 193048 )
          His point was that at least you KNOW about violations, even if they aren't enforced. That's at least something.

          Where it gets tricky is when permissive allows something to happen that triggers another violation, whereas enforcing would have stopped things earlier in the chain. Things can look a little inconsistent in that way.

        • Re:100%? (Score:5, Informative)

          by BigBuckHunter ( 722855 ) on Wednesday June 06, 2007 @05:12AM (#19408359)
          Permissive mode is only useful for policy development.

          I wholeheartedly agree.
          Step 1: Install RHEL, disable SELinux
          Step 2: Install and configure your stack (apache, jboss, tomcat, mysql, whatever)
          Step 3: Enable permissive mode, light up the stack, watch logs
          Step 4: Tweak the rules, repeat step 3 until the logs are clean.
          Step 5: Enable Enforcing Mode

          You can now rest a little bit easier knowing that you have SELinux enabled. The only drawback is that you sometimes have to repeat the process as new versions of your stack are released (mysql, jboss). It's basically a monthly process.

          BBH

      • Re: (Score:3, Informative)

        by Znork ( 31774 )
        "What most people forget is that you can set SELinux to be permissive"

        Unfortunately, there's also a whole bunch of people who naively thought permissive mode would only log and not interfere with anything, spent two days troubleshooting some problem, finally _disabled_ SELinux and had it work perfectly from the default two days ago.

        I'm sure there were perfectly logical reasons for it to happen, but it's that kind of random, seemingly inexplicable and above all, unlogged problems that turn people off of MAC

        • Re: (Score:3, Interesting)

          by arivanov ( 12034 )
          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"

    • Re:100%? (Score:5, Informative)

      by CajunArson ( 465943 ) on Tuesday June 05, 2007 @09:30PM (#19405809) Journal
      100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) [cmu.edu] on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the /etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.
            AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container. I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web. The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).
          Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!

      • AppArmor (Score:4, Informative)

        by hweimer ( 709734 ) on Wednesday June 06, 2007 @02:29AM (#19407611) Homepage
        AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container.

        Some time ago, I wrote a review of AppArmor [osreviews.net], finding that it solves problems that don't exist. Looking at your browser example, the functionality provided by AppArmor can be implemented completely by setting up a different user and setting appropriate file ACLs.

        For the real problems AppArmor provides little help. Can you confine network usage of a program, meaning your internal network cannot be accessed once your browser has been hacked? No. Can you limit the syscalls a program may use, reducing the risk of successful kernel exploits? No.

        As long as it stays this way, I recommend to everyone to use SELinux, even though it is much more difficult to setup and configure.

        • Re: (Score:3, Insightful)

          by FST777 ( 913657 )
          I'm sorry, but your review is more than a year old. For example: it talks about patching the kernel, which isn't necessary anymore (since it uses LSM now).

          Can you confirm that the situation is still like you described? I have no clue at all (been using openSUSE for less than a month now), but I won't take any advise from anyone who points to a year old article about a project under active (heavy) development.

    • Re:100%? (Score:5, Informative)

      by Niten ( 201835 ) on Tuesday June 05, 2007 @09:36PM (#19405837)

      Good GUIs are a wonderful thing, but I want to emphasize that SELinux isn't really all that difficult to begin with. High quality SELinux rules shipped with solid distributions such as RHEL 5 eliminate many of the problems that early adopters faced; indeed, that's more or less the subject of this article.

      Many people (such as myself) consider SELinux much less of a "patch job" than AppArmor. For instance, with AppArmor security attributes are not stored with the filesystem inodes, but are specified according to path name. That might simplify AppArmor's implementation a bit, but consider what happens to the security policy when you have two different path names hard linked to the same inode...

      Those of us who are partial to SELinux's implementation of mandatory access controls are thrilled to see the strides that Red Hat has made in their latest enterprise release.

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        "Good GUIs are a wonderful thing, but I want to emphasize that SELinux isn't really all that difficult to begin with."

        Not difficult? I guess that's why *on a stock Fedora system* SELinux prevents my desktop computer from writing back the time to the hardware clock. Or why SELinux prevents UDEV from creating /dev/watchdog on my laptop.

        If it isn't difficult how come the guys who cobble together the distro can't get it right?

        I just turn it off and life is soooo much easier.

        • Re: (Score:3, Funny)

          by ryanov ( 193048 )
          Wouldn't that be a sign that it's time to get a better distro than to disable security features? :)

      • Re:100%? (Score:4, Insightful)

        by sirambrose ( 919153 ) on Wednesday June 06, 2007 @08:29AM (#19409269)
        The problem in using a selinux system is when most of the software on the system is custom written or custom configured. Although I believe that the using the common combinations of web servers and database servers are easy to combine now, I can easily imagine wanting my web application to do things that are prohibited by policy. Customizing selinux looks somewhat challenging. If you just run a standard mail server or something it is probably great.

        Everybody says that app-armor sucks with hard links, but I just don't see it. If your configuration looks like

        allow all
        deny read,write /root/mysecretfile

        then you have a problem with hard links, but it isn't relevant. In that case you have already decided to try to solve the impossible problem of listing every important file on the system. Anyone interested in security would write:

        deny all
        allow read /etc/daemon.conf
        allow read,write /var/daemon/data

        Then I don't have to attempt to list all the secure files on the system. All I have to do is decide what I want to grant the daemon access to. If there is a hard link to /etc/daemon.conf, the program can't read it and shouldn't be trying to read it anyway.

        Storing the labels in the filesystem only works if you are the distribution maintainer. If all the programs that create a particular kind of file don't agree on the label, the on-disk labels can get messed up. The simple config file in app-armor allows easy auditing.

        That said, I like the possibility of securing dbus and X with the same framework as the filesystem. I'm hoping that we will see a document file access daemon for linux that allows the user to securely load and save files from a sandboxed firefox or openoffice process. Until selinux gets used for this type of desktop security instead of just network daemon security, the added power of selinux is mostly useless.
    • Is there an indepth but easy to read guide on SELinux? I turn it off and rely on a few network based defenses for most of my stuff simply because I don't have two months to dedicate to it. But if there was something I could be flicking through while I post responses on slashdot, I'm sure that would be useful.

      • Re: (Score:3)

        by ryanov ( 193048 )
        Lots of them on the web. I posted my favorite someplace below that was put out by RedHat (easiest for me since it's the manual for the system I'm running anyway).

    • Re: (Score:2)

      by bl8n8r ( 649187 )
      > "I'll dedicate the two next months of my life to learn SELinux"

      Why is learning something new so horrid? I know a lot of admins (sorry, most are windows admins) that are very troubled when they can't fully understand something in 10 seconds. These same guys will sit there staring at a progress bar for two hours during a windows update though (wtf?). Some things worth learning _will_ take time, and some things you learn won't be worth it. You need to take that risk sometimes, even if it seems to suck

      • Re: (Score:2)

        by mkro ( 644055 )
        As someone else just mentioned, there is always a "tradeoff between security and usability". There are lots of admins (and "admins") that are not given the opportunity to learn these things. If they can explain to their managers why they need to learn it, and they are given time for it, fine, but there still are places where the guy running the web server also is the same guy who has to run around the office helping people select the correct printer in Word and restore deleted shortcuts in Outlook. We reall

  • SELinux is a good thing (Score:5, Insightful)

    by pembo13 ( 770295 ) on Tuesday June 05, 2007 @09:10PM (#19405705) Homepage
    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.

    • Re:SELinux is a good thing (Score:5, Insightful)

      by garett_spencley ( 193892 ) on Tuesday June 05, 2007 @09:45PM (#19405891) Journal
      But it all really boils down to your needs.

      For example, consider the typical LAMP server (linux + apache + mysql + php) that hosts a web application. What does it need to protect ? It needs to protect the database with all the user data, the publicly accessible html documents and php scripts and possibly the log files.

      You may also argue that it needs to protect the overall system from compromises involving using the system as a zombie or irc server etc. but in that situation a well managed server could simply have the software reinstalled. If the admins are competent and have access to spare servers they could configure the replacement machine and do a swap without incurring any downtime at all.

      In this situation SE Linux might just be total overkill. The extra paranoid could have the publicly accessible html docs + php scripts on a read-only partition. This is a production environment we're talking about so the need to upload new documents will only be when upgrading software versions. If the web application allows users to upload data then that will need to be handled separately. A cron job could change file permissions on newly updated documents so apache no longer has write access. The log files can be moved to a separate location once per day when they're rotated where apache (or any other services) don't have access to them. MySQL can run chrooted, only bind to 127.0.0.1 and the database files can only have read/write access from the mysql user. Daily, or even hourly, backups of the database to read-only media can be implemented. This is on top of running an intrusion detection system, installing security updates asap, and doing all of your other post-install locking down before the network cable is even plugged in to the machine (setting up your ssh keys, firewalls, uninstalling unnecessary software - including compilers - and obviously unused daemons and anything else the paranoid admin does before the machine goes live etc.)

      We're already talking about way more security than most LAMP based servers out there.

      I agree that the setup could still benefit from SE Linux, particularly for the database since it's still the weakest link and one of the areas in the most need of protection. MySQL needs to read/write to the database on a regular basis and so you need to allow write access to the data files, trust your software, trust your mysql binaries (all binary files and static config files can be on read-only partitions) and nothing is preventing a root process from changing the file permissions or corrupting the data. However, for most people this setup would be more than adequate and SE Linux would be total overkill.

    • Re: (Score:3, Interesting)

      by illumin8 ( 148082 )

      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

  • just how good is this? (Score:3, Interesting)

    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?

    • Re:just how good is this? (Score:5, Informative)

      by sammy baby ( 14909 ) on Tuesday June 05, 2007 @09:19PM (#19405761) Journal
      The short version: it's very good. But a huge pain in the ass.

      The slightly longer version: IPtables is about network access, firewalls, et cetera. SELinux is about ensuring the integrity and access rights of software on your system. It's designed to prevent, say, one process on your machine from overwriting a file it should be able to. There's a pretty good explanation of exactly what it buys you here [nsa.gov]. (Warning: government site. They're watching youuuuuu!)

      The problem with SELinux is that up until recently it has been a royal pain in the ass to configure. You'd go, "Sure, this sounds like a good idea", turn it on, and then curse it roundly when you tried updating MySQL from the version that ships with RHEL to the most recent supported release from MySQL. As a result, most folks just turned it off - they figured it wasn't worth the hassle.

      RHEL 5 apparently includes tools (see the article) for figuring out what's wrong with your SELinux configuration. Definitely worth looking into. But if you're not concerned with validating application integrity on your home box... and let's face it, it's a home box... probably not worth it for you until it becomes dead simple.
      • Damn beer.

        Obviously rather than "prevent one process on your machine from overwriting a file it should be able to," I meant "shouldn't". Feh.
        • Thanks for the info, sounds like its more then I need on my normal use machine.

          Never damn beer, I believe it positively enhances the slashdot experience :-)

      • Re: (Score:2)

        by ryanov ( 193048 )
        I'm not sure that it's at all worth it on a single-user system that is isolated from risky populations by firewalls, etc.

        I don't use it on my personal laptop... actually, that makes me wonder -- I don't know, does Ubuntu even use it by default?

        • does Ubuntu even use it by default?

          I know that Debian Etch does and the user selects the level of protection during install. From then on I guess it does its own thing. There is no man page and I haven't gotten around to reading up on it so I have no clue as to what it is or is not doing. I would guess that Ubuntu uses SELinux in a similar fashion. See if /etc/selinux and /usr/share/selinux exist.

          • Re: (Score:2)

            by ryanov ( 193048 )
            Looks like no... but:

            $ aptitude search selinux
            v libselinux-dev -
            i libselinux1 - SELinux shared libraries
            p libselinux1-dev - SELinux development headers
            p python-selinux - Python bindings to SELinux shared

      • Re:just how good is this? (Score:5, Funny)

        by g1zmo ( 315166 ) on Tuesday June 05, 2007 @10:49PM (#19406301) Homepage

        It's designed to prevent, say, one process on your machine from overwriting a file it should be able to.

        Yeah, that pretty much sums up my experience too.

      • I haven't tried SELinux recently. Basically, it adds a whole lot more permissions and group types and hierarchies to the 3x3 standard "rwx" for user, group, world. You get permissions like "append allowed but no other writes allowed", and "editors running under your account can write to your source code files, but no other apps running under your account can write to those files". Unfortunately, managing all those permissions isn't as easy as running some chmod type of utility. Another knock against suc

        • Re: (Score:2)

          by Alioth ( 221270 )
          The Windowsesque practise of one service per server is still no substitute for SElinux. Presuming you have one service per server, without SElinux, if someone pwns that buggy web app, they can still turn your box into a spam zombie. However, with an SElinux policy, you can lock that web app down so it can _only_ do what's authorized - so when the spammer pwns it, they find they can't actually make any use of what they've managed to pwn, because the SElinux policy on that application prevents it from opening

    • How relevant is it for the normal user?

      I've looked over a few setup guides recently for MythTV on Fedora or Ubuntu (sorry but the urls are on my home machine). They nearly all say "turn SELinux off and save days of configuration pain".

      I can't see the point of persisting with it if you have a SPI router and something like Firestarter.

      • Re: (Score:3, Informative)

        by init100 ( 915886 )

        I've looked over a few setup guides recently for MythTV on Fedora or Ubuntu (sorry but the urls are on my home machine). They nearly all say "turn SELinux off and save days of configuration pain".

        I think those guides may be a bit outdated. SELinux were a royal PITA back in the days, but you almost never run into it on the newer Fedoras. Fedora 7 even has a little icon popping up in the notification area when SELinux denied some access request. For me it have just happened after suspend and hibernate, and then it was only two blocked file accesses.

        I'm actually surprised how well Fedora 7 works. I installed it on my Dell Latitude D810 laptop yesterday, and both wireless network with WPA2, 3D deskt

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

    • Re: (Score:2)

      by dbIII ( 701233 )

      SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability

      If it's for a webserver/ftpserver/mailserver with ssh access it's pretty trivial to set up and use. If it's for something running a commercial *nix app that uses a dozen ports for weird undocumented stuff plus NFS disk access via amd it then becomes a pain.

    • Re: (Score:2)

      by ryanov ( 193048 )
      Walk into your boss and tell them that you've decided to trade security for time (if indeed you're talking about multiuser systems here). My boss would tell me "sorry, that's not your call."

      SELinux is NOT one step above yanking the power cord -- how did this get moderated so high?

      I know, I must be new here.
      • You're right, it's not always my call. But I've never, ever had the call go for security over time, no matter who makes it.

        How the hell did you get a boss with a clue?

        • Re: (Score:2)

          by ryanov ( 193048 )
          You know, I didn't even really get a boss with a clue. The boss that was let go recently (for being a fly in the ointment of the new VP) was originally a UNIX tech who worked his way up. My current boss was a DBA at one point, but years and years ago. Thing is, though, she trusts her staff generally (and can tell when someone's bullshitting her). So there are probably cases where if no one said anything to her, she wouldn't know something was important... but she gets CERT advisories just like the rest of u

      • Re: (Score:2)

        by init100 ( 915886 )

        SELinux is NOT one step above yanking the power cord -- how did this get moderated so high?

        Maybe because it was, back in the days. :)

        In other words, maybe some people need to update their opinions a bit. They install new releases of their distributions, but turn off SELinux just like last time without even looking at the new SELinux configuration tools, etc.

    • I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.

      Stuff can get painful if you go grabbing 3rd-party crap from proprietary developers without neither a clue nor a care.

      Even there though, the popular stuff has already been figured out. For example, suppose you want acroread or flash or vmware. Use google, and search for the stuff being spewed into the log. Skip past the idiots who just disable SE Linux; it may help to add "chcon" (an SE Linux command that

      • Re: (Score:2)

        by init100 ( 915886 )

        it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.

        It may also be easier to remember the chcon command if you know that it means CHange CONtext.

    • Re: (Score:2)

      by jkrise ( 535370 )
      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.

      I simply yank the network cable instead.

      Some good network security tools that I use. [cableorganizer.com]
  • 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].
    • Well actually you don't even need SE Linux.

      First of all, don't make the compiler have setuid-like rights and don't give it arbitrary write control over a home directory. That was pure idiocy.

      For ages, UNIX-like systems have used setgid (not setuid) to solve this for game high-score files. It does allow a bug in the game (an exploit perhaps) to corrupt the files, but your favored solution doesn't fix that either. Linux adds append-only files, which might be desirable for the compiler log example.

      SE Linux is

      • Linux adds append-only files, which might be desirable for the compiler log example

        Linux adds them? They've been in BSD since 4.4BSD, when running at securelevel 1 or above. See man chflags.

        When it comes to security, I much prefer the systrace approach to SE Linux (or SE BSD). It can be turned on on a per-process basis, and simply validates system call arguments, either denying, allowing, or allowing with elevated privilege each one. It's trivial with systrace to let your web server, running as an unprivileged user, bind to port 80, for example, and to enforce a limited chroot, wher

  • 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 usera

    • Re: (Score:3, Informative)

      by farkus888 ( 1103903 )
      saying that you can't install things while selinux is running is a flaw of selinux is like complaining about needing to be root to install things. its job is to keep shit from changing, changes like installing mysql could be done while it was running it wouldn't be doing its job. disabling it long enough to make changes is just like su or sudo to get temporary root access inside your normal user environment.

      disclaimer -- I may be completely off base because I don't use it in a production environment, I di
      • Sure, I've come to the conclusion that that's the only way to use SELinux if you're going to. But Red Hat documentation doesn't suggest that method of administering your server. Also, notice how yum gives no warning about SELinux being on when you use it to install packages? SELinux is always there to bite you, even if you're following all of Red Hat's system administration guidelines. It's not worth the aggravation.

        • Re: (Score:2)

          by init100 ( 915886 )

          Also, notice how yum gives no warning about SELinux being on when you use it to install packages?

          Maybe because it isn't meant to be turned off when installing packages? I've never been bitten by SELinux while installing packages, but of course, I don't use SELinux in a production environment (just on my home desktop and my work laptop) since I haven't yet managed to convince my colleagues to even evaluate if we could turn it on for at least some systems.

    • You can set it to temporarily permissive with setenforce 0.

      Ironically enough when I install systems I leave it enabled, but our security administrator turns it off. He used to try to leave it on but after pulling out what little hair he had, he is opting for the easy solution these days. Fortunately he doesn't set many machines up. I think he'll go back to using it as we move to RHEL 5 since it seems to be more sanely configured.

      You can find a nice note on it at: http://preview.tinyurl.com/yqjmfv [tinyurl.com] which is

      • Re: (Score:2)

        by init100 ( 915886 )

        Ironically enough when I install systems I leave it enabled, but our security administrator turns it off.

        I hope that he just sets it to permissive, as disabling it altogether usually causes a (time-consuming) relabel of the entire filesystem, though maybe only on next reboot.

    • Granted, I'm using something a tad different. I've used all three of Fedora Core 5, Fedora Core 6, and Fedora 7. Not a one of them have had SE Linux prevent yum from working. I just su to root and install stuff. I can't imagine that RHEL would be worse than all 3 of the most recent Fedora versions.

      That's with the default policy. The strict policy is harder, but not by much. You just need to log in with the correct role; this is a RTFM problem.

      • You think I'm making it up? Well, I can prove it with logs:

        May 21 07:56:34 mimir setroubleshoot: SELinux is preventing /usr/sbin/usera dd (useradd_t) "read" to random (random_device_t). For complete SELinux mes sages. run sealert -l 918e1f4a-e9d6-4703-8b36-29d2a444339a

        And I didn't even notice this until just now when I was greping the log:

        May 21 10:01:38 mimir setroubleshoot: SELinux prevented /usr/bin/procmail f rom reading files stored on a NFS filesytem. For complete SELinux m

        • Re: (Score:2)

          by ryanov ( 193048 )
          Did you install something that changed the security context of /dev/random?

          Try "restorecon /dev/random"

          Better yet, run "man restorecon" and then decide what to type.

        • Re: (Score:2)

          by r00t ( 33219 )
          Well, this is really off the wall. I find it hard to believe that the last 3 Fedora releases all worked fine, yet RHEL5 does not. Perhaps it was based on Fedora Core 4? It doesn't sound all that old.

          In case you hadn't noticed, "ls -Z" and "ps -M" are helpful.

  • Just disable it for certain apps (Score:5, Informative)

    by KidSock ( 150684 ) on Tuesday June 05, 2007 @09:43PM (#19405873)
    For those who may not fully understand what SELinux actually does, let me give you an example.

    With SELinux enabled, by detault Apache will be prevented from accessing files other than those of very basic web apps, it cannot open sockets to other hosts, etc.

    For IntErnet applications this is quite reasonable and with the machine on the most hostile network around you really should use SELinux. It won't stop a break in but it can seriously curtail the effects of one.

    For an IntrAnet application that is trying to write to custom log files and talk to LDAP servers and such, SELinux is not going to let you do that. At this point you have two choices - 1) tweek SELinux properties to allow only the specific functionality required by the application or 2) disable SELinux for that entire application. Considering an IntrAnet affords some physical protection, SELinux is less important in that environment and therefore, in this scenario, if you're really not savvy with SELinux and you don't have the time to get into it, I recommend just disabling it for entire application using it.

    For example, to disable SELinux just for Apache you do:

    # setsebool -P httpd_disable_trans 1
    # service httpd restart

    Note that SELinux uses db files that remember these changes so they will persist across reboots and there are no config files to edit. It's a nice system because it's easy to add these commands to install scripts and such.

    So don't get bent about SELinux. Learn enough to disable it for specific apps and then turn it on all over. Keep an eye on the log files. If SELinux is stopping access to things by apps it will report it in the log file. Then determine if the app should be doing that and if so disable SELinux just for that app.

  • Less complex alternatives exist to SELinux. (Score:5, Interesting)

    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: (Score:2)

      by ryanov ( 193048 )
      Undocumented [redhat.com] you say? I think not.

      Something you may not be thinking about -- understanding where you need your permissions on your systems is something that I'd personally recommend REGARDLESS of SELinux.
  • Yes, I've had my share of problems with SE Linux on CentOS. I tend to disable it. I've had SE Linux cause badly configured CentOS Boxes on a CentOS 5.0 Beta (4.92) hang the machine because of SE Linux Policies. However, correctly configured, SE Linux can prevent a unit from being tampered with.

    On the issue of security. There are some Network and Domain Level hiccups. Ideally, all Linux applications should support Kerberos for their Single Sign on facility. However, in a lapse of forethought, there are some

  • We know how to do serious security. Programs have to be divided into big parts that are untrusted, and small parts that are trusted. Only the latter get much in the way of privileges. The key concept is that only a small fraction of the code is trusted, and you make that code simple, paranoid, and well reviewed.

    That's the application model for which SELinux is designed. This was all figured out in the early 1980s and used in a few systems in the DoD community, but the commercial community wasn't worr

    • Sorry, but I don't want to have to get the administrator's permission to write my own program that makes self-modifying code. This is also why a user-local install of Wine is impossible when SELinux is enabled.

      Of course, SELinux does nothing about the problem that a rogue program could pipe out to gdb, a program flagged for ptrace(), and do that stuff anyway.
    • SELinux is an implementation of what everybody - Solaris 10, Windows Vista's protected IE7, Free BSDs- are doing. It's not something from the 80's - in fact it's more like an idea from the 60's that didn't get copied into unix from the start; like ACLs

  • Both right (Score:4, Insightful)

    by Tom ( 822 ) on Wednesday June 06, 2007 @05:13AM (#19408361) Homepage Journal
    Why's there a "however" inbetween. It's both right. SELinux is complex and hard to understand. Heck, I should know I've given speeches at half a dozen conferences about it. And at the same time, it is the most secure option Linux has at this time.

    Yes, there are alternatives.
    Yes, some of them are easier to understand.
    No, none of them give you the level and sophistication of SELinux, not even close.
    No, that's not likely to change very much. Security is hard to do.
  • behind SELinux is good, and it seems to do the job when correctly configured.

    The big problem here is that SELinux is overly cryptic to configure and that the logging regarding access failures are extremely cryptic. This results in a situation where SELinux is often considered more of a problem than an enhancement. The designers of SELinux seems to have forgotten that the log files often are read by humans and that humans act upon the data from the log files and responses from commands issued.

    One such ex

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close