On 06/11/13 01:31, David Sommerseth wrote:
> On 05. nov. 2013 03:25, Steven Haigh wrote:
>> On 5/11/2013 7:12 AM, Connie Sieh wrote:
>>> On Mon, 4 Nov 2013, Stephan Wiesand wrote:
>>>
>>>> I'd like to humbly express my disapproval of habitually placing each
>>>> and every SELinux policy "enhancement" in the security tree. These
>>>> updates are rather expensive in terms of system resources, likely to
>>>> aid a very very small percentage of SL users only (who could just as
>>>> well get them from fastbugs if they're even aware of an issue
>>>> addressed), and have a significant potential of breaking things for
>>>> all the others.
>>>>
>>>> And there's at least one clear mistake in the change note, and two
>>>> places making me wonder whether they're correct, and all three
>>>> paragraphs fail to make it clear to me what actual problem is solved
>>>> by deploying this update. None of this makes me quite confident in the
>>>> QA process this change went through. Which is why I'd much rather
>>>> deploy it only in the course of a minor release update, or if there'd
>>>> be a security flaw fixed, or if I knew it fixes a bug actually biting me.
>>>>
>>>
>>>> Am I the only one feeling that way?
>>>
>>> Lets start a discussion on this.
>>
>> Do many people use SELinux in the enforcing mode?
>>
>> While I'm a bit old school, I don't know many people who even have
>> SELinux in permissive mode - let alone enforcing...
> 
> I've used SELinux in enforced mode since Fedora8/EL5 days (2008).  I'll
> admit there were some challenges those days, but not too much to speak
> of.  With EL6 and newer Fedora's I've not had much troubles with SELinux.
> 
> If I hit some SELinux issues these days, it is usally just wrong file
> labelling (semanage fcontext + restorecon) or just to flip some SELinux
> booleans (semanage booleans/getsebool/setsebool).  The SELinux
> troubleshooter can also provide some nice clues, as can the audit2why
> and audit2allow tools.
> 
> Generally if I suspect I'm having some SELinux issues, I just
> grep "denied" /var/log/audit/audit.log .... normally that's doesn't give
> anything.  But if it does, that's when the fun begins :)  (yes, I really
> find it fun, no sarcasm or irony)
> 
> Permissive mode is basically the same as enforced mode, except that it
> will not block the operation.  But your /var/log/audit/audit.log will
> catch all the denials in permissive mode.  The last option is 'disabled'
> mode, which requires a reboot to disable it all over.  But that's really
> not needed to think of these days.
> 
> I'll recommend you to run in enforced, check audit.log if you suspect
> SELinux causing you troubles.  Then run "setenforce 0" and see if things
> improves.  If it didn't, it's most likely not an SELinux issue at all.
> Run "setenforce 1" to re-enable SELinux again.
> 
> Don't worry!  SELinux isn't as bad as the rumours.

Interesting. I don't think a lot of people I know run SELinux because
the method we use to install SL (on an LV via yum, then chroot for
config) doesn't install the policy for SELinux - so by default, we copy
across an selinux config to /etc/sysconfig/ that has selinux disabled
(as there is no policy!).

It's interesting that the 'yum --installroot=/mnt/template -y
groupinstall base' doesn't include the selinux policy - if it's enable
by default (which it is until you create a disabled selinux config),
then one would assume the policy would be included.

The LV listed as /mnt/template in my example is then spawned off as a
Xen DomU VM...

-- 
Steven Haigh

Email: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299