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."
lol 100% safe
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?
Seems an awful like the different implementations of the same idea.
/., 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?
Of course MS sucks and Linux rules because its
Let the flaming begin
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.
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.
There is no 100% protection. There are only SELinux rulesets for less than two dozen server applications, which is a very small percentage of the over 1100 packages which make up RHEL5. Even so, there's a decent book from O'Reilly, and Linux Journal recently covered SELinux... so only ignorant, overpaid sysadmins would blindly disable SELinux in the datacenter!
"Being a lazy sys admin rarely pays off in the long run."
Is it being a lazy sysadmin? Or just an overworked sysadmin?
There are some neat updates to the wireless networking stuff, adding pretty boxes to make the whole thing somewhat more comprehensible to your average computer user, complete with a huge "this is an open network, anyone can connect to it!" type message.
The update also adds the "information bar" to IE, a little bar that slides down when it blocks a pop-up or activex control. You have to click the bar and then click the right option on the menu to get either things to display. Dialog boxes make more sense: yes/no in activex prompts has been replaced with "install/don't install" and a "never install from [whoever]" option added. "Open/Save" becomes "Run/Save" in the dialog box for download executables. Little shields pop up all over the place to alert you if you're about to do something insecure.
Compare this to SELinux, which -- quite apart from screwing things up whenever I try to install it -- has all sorts of insecure services that no-one would use enabled by default. If you sign up to something like the Mandrake security mailing list, you get a ludicruous number of emails -- and I don't think SELinux has any real equivalent to this completely-hands-off automatic update functionality.
So which OS is more secure? Windows gives you the tools you need, while SELinux gives you just enough rope to hang yourself with.
Incidentally, Snape dies so Harry can kill Voldemort and survive
Making the moon less necessary since 1998.
I've never run an RHEL server for more than 24 hours without experiencing an SELinux problem. Every new release, the same story.
/dev/random. So SELinux blocks reads to /dev/random and useradd hangs which makes yum hang. And yum is one process that I sure don't want to kill.
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
This wasn't a hacked up RHEL box or anything. I had installed it that morning.
There were suggested fixes in my logs, but they did not work. My solution? Disable SELinux. It's just not ready for prime-time. Or production environments.
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.
..,under Trusted Solaris? Or how about a container that provides a trusted environment? Explain.
First, my name doesn't have to be Bruce Schneier to dismiss anybody claiming "100% protection".
/var/www/html to /mnt/data/www/html, after having mkfs.ext3'd some partition and mounted it at /mnt/data. /var/www /mnt/data" as root, I edit /etc/httpd/conf/httpd.conf, changing any instance of /var/www to /mnt/data/www"
/var/www/html to always be the docroot, and /var to be on LVM and online expandable. Ok. Whatever.
Second, I have nothing against SELinux, though I will consider it broken until a default install handles this situation correctly-
1) I install the OS, leaving the default selinux enabled
2) after running a webserver for awhile, I decide I want to move my apache's docroot from
3) naturally after "cp -av
4) I run 'service httpd restart' (reload should work as well of course)
The last time I tried this with a version of redhat/fedora that had selinux enabled, it failed. And for most of the sites I'm serving (many that are never seen outside my home non-internet-connected lan), I see no motivation to invest my time in selinux.
Now mind you, I completely expect things like this to be worked out by the selinux folks, if they haven't been already. The last redhat person I spoke with who defended the above, claimed that they didn't want people mucking around with commandlines and editing configfiles. I then asked that person how I should have gone about changing my DocRoot in such a way that SELinux "just worked". I got no reply. Given no reply, I can speculate as to one- They expect
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.
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 which is on an EnGarde Linux page; they're one of the groups who spend some time studying and working with SELinux.
B) Eliminate all the stupid users. This is frowned upon by society.
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 important ones that do not.
One of these is KDE's Kontact when using XMLRPC. Why is this a problem? If you use Kolab, or eGroupware, you have to manually enter username and passwords for Users. This is a replay vulnerability, and, if your password is changed in LDAP and Kerberos, Kontact doesn't know it, and Kontact repeatedly sends the wrong User name and password to the XMLRPC Server until it blocks the user. Now, with IMAP4 and IMAPS? Click the "Use GSSAPI" Checkbox in server properties in Kontact, and Mail will use Kerberos no problem.
If advanced Linux projects like KDE are serious about security, and I think they are, extensive use of Kerberos in a Domain Environment like mine is a must.
UAC is all about getting the user's input on activities that the Administrator would normally do (but not necessarily want to do if it was done behind their back).
AVC is a way for an end-administrator to customize policy (or get hints on what files or network features to label for access by a service). Generally, the system administrator SHOULD NOT have to create policy unless the administrator is deploying a novel service. And its' not interactive; you don't use it during normal use, you use it during testing to refine your policy.
A similar approach with vastly different intents and use cases.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
SELinux is a huge pain in the ass and most apps don't support it. I know that Cpanel doesn't work with it which is pretty much the industry standard for web hosting control panels. I've even got our kickstart server configured to boot every new server with selinux=0, we simply don't have time to screw around with it trying to make things work.
The traditional unix security model is fine, it's worked for over 40 years, why change it now? People that need more restrictions are free to install selinux, grsec, openwall, or anything else that they want, we don't need SELinux shoved down our throats by Redhat or any other vendor.
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.
Mongrel News all the news that fits and froths
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...)
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 overkill, but we can certainly use it as an alternative to setgid. Make the file world writable. Invent an SE Linux type for it, such as fort_stat_t. Invent an SE Linux role for the compiler, such as fort_r. Mark the files appropriately. Define SE Linux policy such that processes in the fort_r role can only write to files with type fort_stat_t or with the type you use for home directories. Also define SE Linux policy such that nothing else may write to files that have type fort_stat_t.
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.
Like apache or whatever. That's probably the most gain for the least pain. But when you bleeding-edgers get it sorted maybe I'll turn it back on.
For those of us wondering what the article is about, RHEL = Red Hat Enterprise Linux.
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 worried about security back then. Which is how we got into the mess we have now.
Complicating the problem is that these separate parts have to intercommunicate, and interprocess communication on Linux/Unix still isn't very good after thirty years. Pipes and FIFOs are too limited, and shared memory breaks security boundaries. System V IPC is the best mechanism for communication across a security boundary, and it's well supported in SELinux, but almost nobody uses it.
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!
SELinux isn't just for protecting server applications. It's a per-app set of rules for how the program is expected to operate so that it keeps the unexpected from happening. Now, I'll give you that the very nature of free software development will make keeping an external ruleset in sync with a project very difficult. So, it's very unlikely to happen (generating rulesets for the rest of the apps in RHEL, that is).
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
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.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Edit
Make sure you have this line:
SELINUX=Disabled
Save the file and reboot.
Discover that all those things you couldn't get working on Linux suddenly start working meaning no, you don't have to go back to Windows.
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
LOL!
:)
Sorry, NO!
(I have too much to do today!)
However... maybe later, ok? I just have to find time to fit it into my "itinerary"...
->
APK
SELinux appears to be an overengineered, overflexible, poorly deployed, poorly documented, jargon wrapped pieces of software with the dubious distinction of having taken the obscurity of Windows' security model to Linux, with a vengeance.
In fact, its design reminds me of the good ol' Motif apps (maybe this IS a Unix philsophy argh), which popped up in all their blue black and square white glory and could become OH-SO-BEAUTIFUL, you just had to write an app-default file for them: remember the easy syntax, the breezy deployment (just copy it over in 15 different locations, with slight changes in capitalization and name hyphenation), and joyful surprise of the oh-so-totally-unpredictable effects that could be achieved. Users that turned to Windows and its GUI where called stupid lazy lusers then. The type of supporting arguments that are being used runs close to the ones of yore, just replace lusers with admin.
Another (forgotten) lessons from the past would be sendmail.cf which hardworking admins were supposed to write from scratch ($1 ). Now sendmail is much ridiculed, even after a sane configuration system makes it possible to never look at sendmail.cf. xauth and its worthy is another fond memory of something that could neither be understood or made to work (xhost +) until it was made fairly transparent.
ssh and X11 tunnelling, which used to require tens of arcane cli commands and a small chart of the involved IP adresses... Same tune, lazy-admins-i-d-fire-them-if-they-worked-for-me.
Hint: when the vast majority of the perspective users of something DO NOT WANT to even hear about it, then it is not them that should be faulted.
Cheers,
alf
You must be new here.
NetCraft confirms it: BSD is dying.
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 example is the log event below. It obviously tells me that there was an access denied to an object, but it is still rather tricky to figure out which context that I have to adjust (or if I even CAN adjust anything).
And anyway, the information about SELinux that you can get hold of still has some rather deep cracks that seems to originate from the fact that the person writing the documentation thinks it's obvious.
Another problem is that SELinux is riddled with a lot of new terms and it takes time to inhale them, or as you say 'grok' them and their use. To make matters worse you can also look into the sub-realm of SELinux called MLS.
And still - SELinux is still only good for addressing issues of security between different applications. Internal application security is still not addressed. Often this isn't a big issue, but when it comes to complex software as web browsers and their plugins it's really an issue. A web browser of today is practically a virtual machine that executes HTML and other code and allows for remote installations.
This results in problems where malicious people can install their features in this environment to get hold of personal information that the user enters when accessing for example bank services online. This is of course not limited to web browsers but also to other intelligent applications like email applications, word processors etc.
It's not unlikely that a virus like 'Melissa' will appear again, next time utilizing a new hole. Not all viruses are of malicious intent either.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
SELinux when in enforcing mode doesn't even trust me as root. Trying to work with it is/was an exercise in Frustration for me and almost gave me reason enough to dump CentOS 5 and go and install Win2000 to create an Oracle db server in VMware.
In summary, turn SELinux off and my life is much happier.
(THIS IS AN AMENDED & IMPROVED MODEL OF MY ORIGINAL PARENT POST FROM HERE -> http://it.slashdot.org/comments.pl?sid=237507&cid= 19408273 )
INTRODUCTION:
Windows CAN be secured very well, but, you have to go thru some "GYRATIONS/EFFORT" to do it, but, it IS doable (but not to any 100% levels, because again - see what I stated last paragraph of mine above).
BACKGROUND & INFORMATION + TOOLS YOU CAN USE TO HELP YOU SECURE YOUR SYSTEM:
Here I am running Windows Server 2003 SP #2, fully current patched by MS update pages, here (I check it every 2nd Tuesday of the month of course, on "Patch Tuesday's"):
http://www.microsoft.com/downloads/Results.aspx?Di splayLang=en&nr=50&sortCriteria=date
It is a personally 'security-hardened' model I have been working on for many years, using principals I learned & used since the NT 3.5x days onward to this version of the OS: As is now?
I score an 84.735 on the CIS Tool 1.x currently as of 06/01/2007!
(For CIS Tool - There are Linux, MacOS X, Solaris, & other OS models ports of this are available too by the way - not really "ports" strictly speaking, they require JAVA to run)
DOWNLOAD URL FOR CIS TOOL (for multiple platforms), from "The Center for Internet Security" here:
http://www.cisecurity.org/bench.html
(IMPORTANT: This tool IS invaluable in guiding you to a more secure OS, on any OS platform really!)
APK 14 STEPS TO FOLLOW TO SECURE YOUR WINDOWS NT-BASED SYSTEM (2000/XP/SERVER 2003/VISTA):
1.) Windows Server 2003's SCW was run over it FIRST (this only exists on Windows Server 2003, not on 2000/XP (you have to install this, it does NOT install by default) first to help security it (SCW = security configuration wizard, & it's pretty damn good believe-it-or-not, (@ least, as as starting point))...
Directions for its installation are as follows:
Start the Add or Remove Programs Control Panel applet.
Click Add/Remove Windows Components.
On the Windows Components Wizard screen, select the "Security Configuration Wizard" check box, as the figure shows. Click Next.
The Windows Components Wizard builds a list of files to be copied and finishes installing SCW. Click Finish.
DONE! Now, run it... it is very simple to use, and will help even TRIM services you do not need running (which saves Memory, other resources, & I/O to cpu/ram/disk etc. AS WELL AS PROVIDING SECURITY should any services you disable turn up vulnerabilities (this has happened before)).
Then, @ that point? I pull ANY Networking clients &/or Protocols in the Local Area Connection, other than Tcp/IP typically (& disable NetBIOS as well, because I don't need it here), on a stand-alone machine that is not dependent on Microsoft's File Sharing etc. on a LAN/WAN. I also disable that too!
2.) Disable Microsoft "File & Print Sharing" as well as "Client for Microsoft Networks" in your LOCAL AREA CONNECTION (if you do not need them that is for say, running your home LAN)!
3.) Use IP security policies (modded AnalogX one, very good for starters, you can edit & add/remove from it as needed) - Download url link is here for that:
http://www.analogx.com/contents/articles/ipsec.htm
(Search "AnalogX Public Server IPSec Configuration v1.00 (29k zip file)" on that page & follow the directions on the page!)
NOTE: This can be 'troublesome' though, for folks that run filesharing clients though. An alternative to this is using IP Ports Filtrations, in combination with a GOOD software firewall &/or NAT
You don't change the Selinux rules you update the context of the new location. You use the command chcon to change the context of the files.
/test instead of /var/www/html you could use /var/www/html as a reference.
ls -Z will help you find out which one to use.
for instance..
$ ls -lZ
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual
drwxr-xr-x webalizer root system_u:object_r:httpd_sys_content_t usage
You can either explicitly say what context to use or say you modified apache to use
chcon test --reference=/var/www/html
ls -lZ
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t test
Most mysql problems are solved the same way. SeLinux can be very complex, but the default rules provided in RHEL typically just require context changes on files and directories to make non RedHat packages work.
Linux Journal just published a case study I wrote on how SELinux protected a Red Hat Enterprise Linux 4 server from an attack on a Mambo installation:
7 -07/bt9176
http://www.linuxjournal.com/xstatic/abstracts/200
You can find the article in the July 2007 issue of the print magazine, or read it on the web if you are a Linux Journal subscriber. Linux Journal typically opens up their archives to public access a couple months after publication, also, though I would encourage people interested in Linux to subscribe to support this quality magazine.
Since writing the article, I've also helped another company with a postmortem analysis of a different Mambo exploit that RHEL 4's SELinux implementation also stopped.
root@host# restorecon -r /directoryThatContainsModifiedFiles
You can run the command above on / if you have lots of time to kill.
root@host# system-config-selinux
The GUI tool above shows you all the SELinux booleans that affect server applications (e.g. there are some Samba booleans you have to flip to enable the sharing of home directories) and will actually allow you to disable it for specific pieces of software if you need to get something up and running quickly while leaving SELinux in Enforce mode.
I don't understand why RSBAC is never mentioned on slashdot, some sort of pro fedora bias?
RSBAC is far more versatile, and more in line with the UNIX mindset, far more stable, and generally better.
Thoughts?
www.rsbac.org