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

SELinux is a good thing

[pembo13]

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

[garett_spencley]

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.

AVC (server) = UAC (desktop)

[OutOnARock]

Seems an awful like the different implementations of the same idea.

Of course MS sucks and Linux rules because its /., but how is "training" AVC to know what is allowed to touch the kernel and what is not, any different from "training" UAC to know what is allowed to touch the kernel and what is not?

Let the flaming begin

Re:100%?

[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:anecdotes...

[ryanov]

Just because you don't know how to do something doesn't make it broken. There are additions to almost all of the common GNU fileutils that support SELinux. You could alias them in .profile or equivalent if you wanted, like many distros do with -i on rm, etc.

Of course, it sounds like many of your uses don't call for it, but really, what's next? Saying "I yelled at the PC to copy my files -- it didn't. Until they work this out, I consider it broken."

Both right

[Tom]

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.

Re:AppArmor

[FST777]

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

[sirambrose]

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.