Red Hat Boosts SELinux With RHEL 5

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

Comments

100%?

[mkro]

There will never be a 100% protection. A good GUI with a wizard, like with SUSE's AppArmor, 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%?

[weapon]

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:100%?

[CajunArson]

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

Re:100%?

[Niten]

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:100%?

[ryanov]

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 problems go away.

I run a ColdFusion server with SELinux enabled (permissive yet, but I'm getting there)... that is a bit of a challenge, but it protects me from questions later, like "why was that privilege escalation possible?"

Re:100%?

[Anonymous Coward]

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:100%?

[ryanov]

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%?

[BigBuckHunter]

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:100%?

[Znork]

"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 security. It's not unique to SELinux, I've seen the same kind of crap on other systems like eTrust.

And unfortunately, once you start distrusting the security software (and it doesnt take many instances of such failures), the first line of debugging always becomes - shut it off, shut it off completely and utterly, because I'm not wasting my time again.

"I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies."

I'd say it's the the most important part of the problem. For some reason, designers of these kinds of softwares tend to act as if it's a wholly separate part of the system, with the common result that they're signalling errors in encrypted morse code on a LED on the dark side of the moon. There are standard ways to signal system errors, standard header files defining system messages, and many programs use these facilities to signal what was wrong (such as permission denied). It would be far more acceptable if these were used, and a program would signal 'Permission denied by MAC policy', which would give an easy way to know what to fix.

Re:just how good is this?

[sammy baby]

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

Just disable it for certain apps

[KidSock]

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.

Re:SELinux is a problem

[farkus888]

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 disable it during install whenever putting a fedora box up for use.

SE Linux is rarely noticable and easy to fix

[r00t]

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 fixes many such problems) to your google query.

Typically you find instructions for some "chcon -t foo_t /usr/lib/libfoo.so" command, often needed because the app developers were total idiots who couldn't figure out how to run gcc correctly. Run that and be happy.

(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)

example: text relocations

[r00t]

Common problem: you built a library (a *.so file) without compiling all the object files (the *.o things) with gcc's -fpic or -fPIC option, and/or you forgot to specify -shared when linking.

When you make this kind of screw-up, you cause something called "text relocations". These don't even work on non-x86 and Debian bans them anyway for reasons related to memory usage. A text relocation means that the loader patches the code itself, rather slowly, when loading the shared library. This requires memory to be both writable and executable, which is a no-no for security against buffer overflows. SE Linux is usually set up to prohibit this by default.

If your broken shit runs as a server or gets loaded into a web browser, you greatly decrease security. You suck. Fix your shit.

I'm a developer too. I've upped my standards. Up yours!

AppArmor

[hweimer]

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, 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:How relevant?

[init100]

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 desktop with Compiz on ATI Radeon Mobility X600, suspend and hibernate works fine out of the box. Never did before. And of course, running with SELinux enforcing and see almost no warnings.