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