Posts Tagged SELinux

Why I’m becoming increasingly disillusioned with SELinux

My history with SELinux is a… varied one.

I first remember using it back in Fedora Core 6. I soon gave up on it, the labeling wasn’t consistent and I didn’t have the time nor inclination to relabel everything, especially when a quick one work change in a config file fixed all my problems.

The next time I used it was probably in F10. I ended up disabling it then, for much the same reasons.

Then I got onto F12/13 for my home server, and disabled SELinux again pretty darn quickly, after neither samba nor Apache liked it.

I can’t remember if I ever disabled it on my testing server which was running F15. But when I upgraded the server to F16Beta, I quickly rediscovered SELinux. Mainly because I’d get errors like this one:

avc:  denied  { read } for  pid=1868 comm="dhclient-script" name="ifcfg-br0" dev=dm-4 ino=10894 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

As far as I can tell, that’s SELinux denying the default network setup script from running. br0 is my custom xen bridge, I’ll admit, but it was working fine in F15, and even F16B until a new update came out sometime on or about Oct 20, breaking the network script.SELinux probably lasted the longest on F16B so far, because, for the most part, it worked perfectlyfine until, well, it just didn’t work.

  1. Sudo -i just  didn’t work. I spent about 30 minutes trying to hunt down what was causing the problems – checking /etc/groups, running visudo, the whole shebang. Everything said “Yes, I should be allowed to use sudo!” But sudo would perpetually tell me “User kyl191 is not in the sudoers file. This incident will be reported.”, and it was. My root terminal would get an extra line reading “You hve new mail” after any command was run.
  2. Starting up VMs just outright didn’t work, SELinux blocked access to the disk, but it was never relayed back to xen – Xen would just die with the exception “Cannot find bootloader”. That was my first inkling that SELinux is still in force.
  3. Last straw, SELinux killed my networking setup when it did…. something after an update that was published on/around Oct 21.

Some will argue that my ifcfg-br0 script is in the wrong context, so of course it would fail. To that my only response is “So…what context should I use then?” I’ve got no clue, and I’m sorry, but I’m not about to spend time looking for a list of contexts, and trying to apply them to each and every file I encounter in such a situation.

I’ve trying to write documentation for the Xen project. On my testing server, I’m not going to bother enabling SELinux because it gives me strange errors. For prod servers, I might use it if there was a VM for each service, otherwise the resulting mish-mash of programs tend to lead to unexpected results.

, ,

No Comments

SELinux, Xen & LVMs

I discovered something new today: SELinux can and does prevent access to logical volumes. This is entirely unexpected for me, because I always thought SELinux only worked on files.

I was wondering why my test VM suddenly refused to start with the error “Disk is not accessible” after I upgraded it to F16Beta. I checked the dom0 logs, and read “couldn’t find bootloader”. At which I promptly went “Oh, crud, grub2 screwed up again!”, and promptly ignored it because it was after midnight.
Then I tried again today. The main difference being that I dropped out of X, and had the screen on when I started up the domU. So I caught these messages:

[  946.283648] avc:  denied  { read } for  pid=3193 comm="xend" name="dm-6"
[  946.690625] avc:  denied  { open } for  pid=3194 comm="pygrub" name="dm-6"

At which point I went “Oh, I see. Oops.”

Simple fix was to disable SELinux with a “setenforce 0” command. More extensive fix would be to:

  1. Find out why SELinux was suddenly enforced OR only just started blocking my Xen disk access
  2. Relabel the LVs so SELinux doesn’t throw a fit.

With regards to relabeling the LVs, the exact problem that SELinux has seems to be this:

scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0

The context xend is running under is xend, while the context of the LV is that it’s a fixed disk.

Research says

semanage fcontext -a -t xen_image_t "/dev/mapper/vg_caesium_domU*"

should work, but no guarantees – just did it, and ls -lZ was unchanged. =|

(Filed a bugzilla bug on this: bugzilla.redhat.com/show_bug.cgi?id=747662)

,

No Comments