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."
SELinux is a good thing (Score:5, Insightful)
AVC (server) = UAC (desktop) (Score:1, Insightful)
Of course MS sucks and Linux rules because its
Let the flaming begin
Re:SELinux is a good thing (Score:5, Insightful)
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:100%? (Score:2, Insightful)
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
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... (Score:3, Insightful)
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 (Score:4, Insightful)
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 (Score:3, Insightful)
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:4, Insightful)
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
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
allow read,write
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
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.