On 08/12/10 16:03, William Warren wrote: > On 12/8/2010 9:13 AM, Christopher Chan wrote: >> On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote: >>> On 12/8/10 4:22 AM, David Sommerseth wrote: >>>> On 30/11/10 03:52, cpolish at surewest.net wrote: >>>>> Christopher Chan wrote: >>>>>> Les Mikesell wrote: >>>> [...snip...] >>>>>> As was already mentioned in another post, run in permissive mode, for a >>>>>> few days if you must, and go through all the things the software does >>>>>> and voila! setroubleshoot and/or logs tell you what needs doing. >>>>> Very optimistic, that. In my shop, some things run annually. >>>>> A comprehensive system test = production, for a year. Just >>>>> this morning a 1099 (annual tax-form) script failed in test. >>>> So you would rather disable SELinux completely - 365 days a year, rather >>>> than to switch to permissive mode when running this script once a year? >>>> >>>> I'm sorry, but I'm not able follow that logic. >>> In our case if something fails once a year we lose customers and money. I'd >>> expect that to be fairly common. >>> >> Again, that particular process is unlikely to be missed and also show to >> be easily mitigated by doing a realtime switch from enforcing to >> permissive. Such annual processes are fairly common and usually run >> manually. You have yet to make a compelling case for completely >> disabling SELinux just for this sort of thing. >> > loosing customers and money on an annual basis is a great reason to kill > it. Make it able to work without updates interfering with a formerly > running configuration on a regular basis and more folks will adopt it. > Saying killing it because it is hurting your business isn't a valid > reason is arrogant and frankly stupid. Frankly, there's several other > distros that don't run SeLinux and they aren't anymore problematic when > properly configured than RHEL is..and they just work. Let's put the > SeLinux religion aside..make it not only technically superior but > actually usable and helpful and you'll see a wider adoption. The kind > of arrogance I've seen in this thread is a primary reason it won't get > appreciable traction outside of RHEL and why it won't be a major tool in > admins toolbox inside RHEL unless folks don't NEED the flexibility Linux > in general offers and SELinux restricts. And that *is* the key point! The basic SELinux stuff which most users need to know about *isn't* as hard as people want it to be. Really!! I've been fighting with it for some time, until I took the time to learn about it. After that, it's pretty much an easy breeze. My biggest mistake in my learning process was that I made SELinux much more complex and chaotic in my head than what it really is. Anyhow, no matter which technology you're talking about, if you don't spend time learning it, it will be difficult until you learn it. To complain about a technology as non-functional or being bothersome without having tried to learn it, is a moot argument. Of course, there are most probably a lot of things which can make things even more intuitive. But I struggle to see those issues right now. There was a suggestion which sounds good at first glance earlier on here, that it should be a tool you could point a directory at ... and it would give some clues which files where "breaking" the file security context in the policy. That does sound like something helpful. Otherwise, don't make SELinux more complex than what it really is. The core concept is basically a different way how to restrict access for processes - on the same level as chmod, uid/gid and ACLs does on files. SELinux only does this even more fine grained and with ways to also restrict access to other things than only file access. "Science should explain things as simply as possible but no simpler" - Albert Einstein Btw ... Debian 5.0 (Lenny) ships with SELinux packages installed by default, but not enabled. They seem to be moving into the SELinux direction as well. <http://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html> kind regards, David Sommerseth