Tim: >> There's been a few examples where running SELinux in permissive mode has >> been found to still restrict things, looks like you found another. Gene Heskett: > I guess so Tim. How can I go about ripping it out totally? You have three basic settings: [1] Setting it disabled, means disabled (as far as I've read - *that* does what it's supposed to). [2] Setting it to permissive is supposed to mean things still work, but activities are logged (rather than blocked), but that's been found to have flaws. [3] And setting it to be enabled. *Then* you've got policies which set what's allowed and disallowed, fine-tuning what enabled is supposed to do. > To me, this is many times more trouble than ANY perceived security is > worth. I'm already bulletproofed from the outside Careful not to believe that. You might be difficult to mess about from outside, but you're not totally immune. All it takes is something like an exploit in your web browser, exploiting some other flaw in your system, and you get messed with. Though I tend to feel that we're falling in the Windows anti-virus, anti-this, anti-that, manner of thinking - rather than fix flaws in a system, we're going to rely on something *else* to protect us from them. > and nothing selinux can do will make it bulletproof against me. Yes, well that's always going to be the case. Whatever protective system is used. People will ignore warnings, blindly allow things when asked, without thinking about it, and so on. ... Run as root... (none too subtle dig, there) ;-) > All its doing is frustrating me to the point of screwing things > royally up just trying to figure out how to do what I'e been doing for > years when it decides to kill amanda, apparently for no good reason > that I can grok. About the only trouble I've had with it has been with Apache. Since that is about protecting me from what outsiders might try to do to me, I have put the effort into trying to do it right. Though there's one or two things that I couldn't figure out how to do smartly. e.g. I had a program that would display local man pages through the webserver. Quite useful, for what I was doing, at the time. But SELinux wouldn't let it do it, because it'd be reading files that weren't meant for webserving. Changing those files to have a webservable context wasn't a good answer, and would be undone by the next relabel, unless I re-wrote the default policies. Allowing the webserver to serve files not meant to be webserved, wasn't a great idea, either (because it would apply to all files, not just the few that I wanted it to). But, ultimately, it was the one option that was going to behave the same from one "yum update" to the next. -- (Currently testing FC5, but still running FC4, if that's important.) Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
