Slashdot Mirror
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."
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.
I shall go and tell the indestructible man that someone plans to murder him.
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.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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?
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.
Too late to be known as Bush the First, he's sure to be known as Bush the Worst.
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. 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.
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.
i can sell you a 100% safe pc if you want - it has no hd and no psu.
If you mod me down, I will become more powerful than you can imagine....
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.
thats right, I rarely use capitals. deal with it. but don't mistake my laziness for stupidity
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/
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.
Very off topic, but I was just thinking...
windows with it's constant prompts to do stuff while performing the same task gets very annoying and will quickly train the user to just click the allow, rendering it practically pointless.
Clearly, in order to make users think about this, a 5 second delay has to be introduced before the Allow/Deny buttons are active...
So where do I go to sign up for one of those consultants jobs then. I'm sure I could turn off SELinux just as well as anyone else.
GCS/S d-x s+(+): a C++++$ UL+$ P+ L++$ !E--- W++@ N++>$ !o !K-- w++$ !O !M !V PS++>$ PE !Y PGP+ t+ 5++ X++ R tv b
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."
Great, after decades with --archive --verbose being sufficient cp flag knowlege, now I have to pay attention to some new crap. (i.e. the main point I was making). Somehow having to learn to deal with and use --sparse for tar seemed less offensive to me. Mainly I suppose because the --sparse gives me immediate satisfaction of seeing the benefits of a new feature (i.e. free disk space, smaller files, etc...). Wheras the --preserve=context and selinux only give me "security". Personally I'll stick with the philosophy that security should be part of the foundation, invisible to the user interface. (not that I won't use selinux where appropriate, just that I'll continue to be vocally annoyed).
I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.
/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.
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
(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)
I think at some point, SELinux was touted as being a *transparent* security enhancement. Which sounded really cool to me. Then I discovered that it was a _vastly complex beast that required constant attention in order to prevent breakage of applications in situations where those applications were being used precisely as the application developers had intended_.
SELinux is hard to use. The amount of energy required by my brain to contemplate MAC policies for all the types of situations I run into, is not worth the security it is bringing me.
Just because all the coders who wrote the linux kernel, apache webserver, and distribution I was using didn't know how to implement SELinux's features in the first place, does NOT mean that they were stupid, or that their code was broken.
The question is whether or not selinux is worth the trouble. I'm arguing (not alone dare I say) that in a lot of situations (majority? vast majority?) it is not. But don't give me this bullshit about 'because I don't know how to use it doesn't mean it's broken'.
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
Learning HOW to think is more important than learning WHAT to think.
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'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.
OS Reviews: Free and Open Source Software
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.
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.
Assorted stuff I do sometimes: Lemuria.org