[aklug] Re: Warning: Rant ahead. Was: selinux more trouble than it's worth?

Thanks Lee,
I am glad to know I'm not the only one needing an eraser on my pencil,
: )

Lee wrote:
> Well, I was getting ready to fire off one of my trademarked pithy replies to the effect
> 'done that, didn't work'. I went in to copy the selinux config file and saw I'd
> un-rem'ed the wrong line.
>
> Original:
>
> # cat /etc/sysconfig/selinux
> # This file controls the state of SELinux on the system.
> # SELINUX= can take one of these three values:
> # enforcing - SELinux security policy is enforced.
> # permissive - SELinux prints warnings instead of enforcing.
> # disabled - SELinux is fully disabled.
> SELINUX=enforcing
> # SELINUXTYPE= type of policy in use. Possible values are:
> # targeted - Only targeted network daemons are protected.
> # strict - Full SELinux protection.
> SELINUXTYPE=targeted
>
> Changed to:
>
> # cat /etc/sysconfig/selinux
> # This file controls the state of SELinux on the system.
> # SELINUX= can take one of these three values:
> # enforcing - SELinux security policy is enforced.
> permissive - SELinux prints warnings instead of enforcing. <-
> # disabled - SELinux is fully disabled.
> SELINUX=enforcing
> # SELINUXTYPE= type of policy in use. Possible values are:
> # targeted - Only targeted network daemons are protected.
> # strict - Full SELinux protection.
> SELINUXTYPE=targeted
>
> Should be:
>
> # cat /etc/sysconfig/selinux
> # This file controls the state of SELinux on the system.
> # SELINUX= can take one of these three values:
> # enforcing - SELinux security policy is enforced.
> # permissive - SELinux prints warnings instead of enforcing.
> # disabled - SELinux is fully disabled.
> SELINUX=permissive
> # SELINUXTYPE= type of policy in use. Possible values are:
> # targeted - Only targeted network daemons are protected.
> # strict - Full SELinux protection.
> SELINUXTYPE=targeted
>
> It's interesting that general consensus (here and other places I bitched about this at)
> is to 'disable the security' to one degree or another. There's a moral there. I go to
> security conferences every once in a while, and those folks all bemoan that the 'user'
> or 'developer' or 'administrator' or 'anybody else' is the problem, and they bitch that
> the first thing everyone does is turn off or otherwise compromise the security of a system.
>
> Excuse me. The system -exists- so people can do work, be productive, etc. If they
> can't do that then the system immediately becomes a boat anchor (or more likely a
> millstone around somebody's neck). So the problem is not the user, the problem is the
> thing that keeps the user from doing his or her job in an effective and efficient
> manner. You can fill in the rest of the argument. It's old and standard rote.
>
> Now, somebody always pipes up and says 'disable the security, tune it, work with it, and
> reenable it'. Sounds good. In an ideal world there's time to do that. You know very
> many in the workplace that have the luxury of being able to take the time to do things
> right, rather than have to get it done right now?
>
> I don't know the answer. I wish I did. But the current practices and paradigms aren't
> it. Fiendishly complex passwords that expire every thirty days or three tries aren't
> it. Disable by default isn't it (remember novell netware?)
>
> But even if I did, there'd be all sorts of squabbling and resistance and NIH and
> obstructionism and whatall (remember the squabbling over RSA and PGP in the 90's?)
> Someone mentioned PK a bit earlier (and there's RSA SecureID and their ilk); that may be
> the right path, but I bet it turns out to be like the X.509 mess, so complicated and
> tied up in so many knots and so many special interests that it's hopelessly broken, as
> the firefox folks have discovered and refuse to admit.
>
> Ah well, I normally allow myself a ration of one rant a week, and I'm up to three just
> for today, so I'd better stop before the keyboard breaks.
>
> Peace and Long Life and all that.
>
>
>
> ---------- Original Message -----------
> From: adam bultman <adamb@glaven.org>
> To: Lee <lee@afabco.org>
> Cc: barsalou <barjunk@attglobal.net>, aklug@aklug.org
> Sent: Tue, 02 Jun 2009 14:08:45 -0800
> Subject: Re: [aklug] Re: selinux more trouble than it's worth?
>
>
>> On Centos or RHEL,
>>
>> system-config-securitylevel
>>
>> Or,
>>
>> vi /etc/sysconfig/selinux
>>
>> And set to "permissive" instead of "enforcing".
>>
>> Adam
>>
>> Lee wrote:
>>
>>> That's 'permissive' mode. That's what it is at now (which I fortunately discovered
>>> early on, but I still get all the stupid popup boxes on the desktop). Plus centos
>>> (and presumably RHEL as well) 'helps' you by re-activating the 'active' mode on
>>> reboot. Yes, I know we're supposed to never have to reboot, but I do anyway,
>>> particularly on setups and installs.
>>>
>>> I could do a cron job to reset it to 'permissive', but that's ugly, and shouldn't even
>>> have to do that at all.
>>>
>>> Thanks though.
>>>
>>> Lee
>>>
>>>
>>> ---------- Original Message -----------
>>> From: barsalou <barjunk@attglobal.net>
>>> To: Lee <lee@afabco.org>
>>> Cc: aklug@aklug.org
>>> Sent: Tue, 02 Jun 2009 11:29:52 -0800
>>> Subject: Re: [aklug] selinux more trouble than it's worth?
>>>
>>>
>>>
>>>> Quoting Lee <lee@afabco.org>:
>>>>
>>>>
>>>>
>>>>> Well, I've just spent the last two days setting up a centralized
>>>>> syslog server on bare
>>>>> metal.using centos5, mysql, php, phplogcon and apache2 All went
>>>>> well until I actually
>>>>> started trying to, like, do useful stuff.
>>>>>
>>>>> Nothing worked as expected.
>>>>>
>>>>> 9 out of 10 issues were selinux related.
>>>>>
>>>>> And there are still issues, but at least stuff is working now.
>>>>>
>>>>> So it seems to me at this point that selinux is way the hill more
>>>>> trouble than it's worth.
>>>>>
>>>>> But before I deactivate selinux in disgust and consign it to the
>>>>> 'interesting idea way
>>>>> more trouble than it's worth in real life' pile, I thought I'd see
>>>>> if others shared my
>>>>> thinking, or whether consensus is that selinux is seen as a useful
>>>>> and practical thing.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>> As you've discovered, figuring out what it affects and how to mold it
>>>> to your needs is the hardest part.
>>>>
>>>> I'd like to suggest that you turn the setting to 'warn' or 'audit'
>>>> Can't remember the name it was given....it's not on, but it's not off
>>>> either.
>>>>
>>>> This will give you logging information to let you know that if you
>>>> have it turned on, then these things will be an issue.
>>>>
>>>> Give that a try....you'll get the best of both worlds....being able to
>>>> get stuff done, and knowing what needs to be modified so that stuff
>>>> will continue to work when you turn it on for good.
>>>>
>>>> Just an idea.
>>>>
>>>> Mike B.
>>>>
>>>> ----------------------------------------------------------------
>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>
>>>>
>>> ------- End of Original Message -------
>>>
>>> ---------
>>> To unsubscribe, send email to <aklug-request@aklug.org>
>>> with 'unsubscribe' in the message body.
>>>
>>>
>>>
>> --
>> Adam
>>
> ------- End of Original Message -------
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Jun 2 21:11:01 2009