Edit stub and remove
      <model>SandyBridge</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='osxsave'/>
      <feature policy='require' name='pcid'/>
      <feature policy='require' name='pdcm'/>
      <feature policy='require' name='xtpr'/>
      <feature policy='require' name='tm2'/>
      <feature policy='require' name='est'/>
      <feature policy='require' name='smx'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='ds_cpl'/>
      <feature policy='require' name='monitor'/>
      <feature policy='require' name='dtes64'/>
      <feature policy='require' name='pbe'/>
      <feature policy='require' name='tm'/>
      <feature policy='require' name='ht'/>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='acpi'/>
      <feature policy='require' name='ds'/>
      <feature policy='require' name='vme'/>
    </cpu>


Client starts.
Worked on 6.3.

Description of problem:
Upgrade to RHEL 6.3 Snapshot 4.

Should read

Description of problem:
Upgrade to RHEL 6.4 Snapshot 4.

Created attachment 680303 [details]
libvirt log

2013-01-17 15:46:32.520+0000: 3156: error : virSecuritySELinuxMCSFind:135 : internal error Cannot parse sensitivity level in s0

We run SELINUX in permissive mode-

Can you provide output of the following command

$ ps -axuwfZ | grep libvirtd

system_u:system_r:initrc_t:s0   root      3152  0.0  0.3 1027616 11436 ?       Sl   10:45   0:01 libvirtd --daemon
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 5184 0.0  0.0 103244 824 pts/1 S+ 11:28   0:00              \_ grep libvirtd

I don't know how, but you seem to have got your libvirtd running under the wrong SELinux context. Rather than initrc_r:s0 it should be virtd_t:s0-s0:c0.c1023 eg

system_u:system_r:virtd_t:s0-s0:c0.c1023 root 23927 0.4  0.2 1087724 20676 ?   Ssl  14:24   0:36 /usr/sbin/libvirtd


Try running 'service libvirtd restart' to see if that fixes the context

Restarting it does not fix the issue.

We have selinux running in permissive mode.

Should not be impacted.

If you are running in permissive mode, all SELinux functionality is still enabled. It merely means that the final access control result status is ignored.

What does this show

 ls -alZ /usr/sbin/libvirtd

rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/sbin/libvirtd

Ok that explains it, the labelling on your filesystem is screwed up. it should be 

  rwxr-xr-x. root root system_u:object_r:virt_exec_t:s0   /usr/sbin/libvirtd

If that's wrong I imagine other things are wrong too, so run the following as root

  # touch /.autorelabel

and then reboot the machine & let it fix all the labels. Then libvirt should work as normal

A relabel worked.

Kind of confused why this worked in 6.3.

I would thought permissive would just log errors, not prevent the client from starting.

I agree totally our labelling is incorrect, however.

"If you are running in permissive mode, all SELinux functionality is still enabled. It merely means that the final access control result status is ignored."

In this case the the final access control result status is NOT ignored.

It should only exit if enforcing is enabled.

Well, it wasn't any kind of access control that failed. It was "virSecuritySELinuxMCSFind:135 : internal error Cannot parse sensitivity level in s0" which means that libvirt expected different label than with it got and thus failed to parse it. This has nothing to do with permissive or enforcing mode. In 6.3 it worked because you didn't have incorrect labels on your filesystem.

Jiri, 

"This has nothing to do with permissive or enforcing mode" - I realize this is not checked. 

This is a new feature that has been added in libvirt 0.10.2 it is not part of 0.9.10 builds.

Ah right, the main code that is supposed to find a free MCS label was there even in older libvirt. In newer libvirt, the code was enhanced and thus it is less tolerant to this kind of error. In any case, this is not a bug. Thanks for confirming that relabelling the filesystem makes things work.

Performed some more tests.

TEST A
I performed a clean install of 6.3, upgraded to 6.4, rebooted
Result(S0 error)

system_u:system_r:initrc_t:s0   root      3092  0.2  0.2 830784  9212 ?        Sl   10:50   0:00 libvirtd --daemon
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4391 0.0  0.0 103240 888 pts/0 S+ 10:52   0:00 grep libvirtd
-rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/sbin/libvirtd

TEST B
touch /.autorelabel && reboot
Result (Working)

system_u:system_r:virtd_t:s0-s0:c0.c1023 root 3084 0.2  0.2 962044 8504 ?      Sl   10:37   0:00 libvirtd --daemon
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4487 0.0  0.0 103240 884 pts/0 S+ 10:39   0:00 grep libvirtd

-rwxr-xr-x. root root system_u:object_r:virtd_exec_t:s0 /usr/sbin/libvirtd

TEST C
Force reinstall libvirt.
rpm -Uvh libvirt-0.10.2-15.el6.x86_64.rpm --force
Result(S0 error)

system_u:system_r:initrc_t:s0   root      3092  0.2  0.2 830784  9212 ?        Sl   10:50   0:00 libvirtd --daemon
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4391 0.0  0.0 103240 888 pts/0 S+ 10:52   0:00 grep libvirtd
-rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/sbin/libvirtd

Any clues to why the label gets altered on an upgrade/for reinstall, however relabel is fine.

Looks like something is wrong with rpm or selinux-policy, then.

(In reply to comment #19)
> Looks like something is wrong with rpm or selinux-policy, then.

Reopening

Reassigning to selinux-policy for further investigation. Just to be clear, with "rpm" I meant the rpm component rather than libvirt rpm packages.

All,
	after hours of testing ... I found out why the "bug" occurs, but not the root cause or a fix.

When we build a live image, in the kickstart we currently use.
selinux --permissive 

This is should be valid, same setting is used by our network installs, where it works.

However it would appear to prevent selinux from working correctly, when used with a livecd.

If we create a live image using.
selinux --enforcing
This works correctly, irrespective if we install an RPM to enable permissive in the image itself.

i.e.
Create 2 LiveCDs

Using the following ks(see attched)


Diff.
--- permissive.ks	2013-01-22 08:44:21.393003669 +0100
+++ enforcing.ks	2013-01-22 08:44:07.776043797 +0100
@@ -2,7 +2,7 @@
 keyboard us
 timezone US/Eastern
 auth --useshadow --enablemd5
-selinux --permissive
+selinux --enforcing
 firewall --enabled --service=mdns
 xconfig --startxonboot
 part / --size 4096 --fstype ext4

Boot and install both livecd's. 
Change the settings for selinux in both examples to the below & reboot.
/etc/selinux/config 
# 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

Now perform the test :-
  Force install libvirt.
  rpm -Uvh libvirt-0.10.2-15.el6.x86_64.rpm --force --nodeps

  Check label
  ls -laZ /usr/sbin/libvirtd

  Enforcing livecd install works.
  -rwxr-xr-x. root root unconfined_u:object_r:virtd_exec_t:s0 /usr/sbin/libvirtd  
  Permissive livecd install does not work.
  -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/sbin/libvirtd

- Relabel the whole filesystem, changing settings in /etc/selinux seem to have no impact. 
- Switching to enforcing relabel, reboot, permissive, relabel reboot do not resolve
the issue. 
- A recursive diff through the 2 filesystems - no difference

If a live image has been created using "selinux --permissive" then installed, selinux will not update labels correctly automatically.

Created attachment 684955 [details]
KS permissive

Created attachment 684956 [details]
KS enforcing

Created attachment 685194 [details]
sysreport permissive install

Created attachment 685195 [details]
sysreport enforcing install

What we need to know is how to get SELINUX to update the file context (on the fly) when the clients have been installed using the livecd created with selinux --permissive.

Seems to be a bug in livecd tools. I would have no idea why --permissive would be any different then --enforcing.  Labelling is done based off the /etc/selinux/POLICYTYPE/file/file_context file.  But really the --permissive flag only changes the content of /etc/selinux/config.

On the other problem, I am not sure if there is a good fix for libvirt running with a limited range of MCS Labels.  I guess in permissive mode it could just execute the virtual machine without changing its label, rather then refusing to launch the virtual machine.

Thanks for responding Dan. 
I am curious how to get the automatic labelling working again.
Can you think of anything else to try.

Last time I looked, the last phase of a livecd create was to relabel the entire image, using setfiles.

Post install the labels are set correctly user either livecds.

The issues seen are.
a - you boot the permissive created livecd and install a package, labels are not updated.
b - you boot and install the permissive created livecd and install a package, labels are not updated.
Its like auto update labels is turned off.

In the case of the enforcing created livecd, it labels correctly both live and install.

Then this sounds like an RPM issue.  RPM should be putting the labels down in either case.  If you boot the livecd permissive and set it enforcing then install the package does the labelling work?

There are some flags that can be handed to RPM to turn off labeling but I don't see how permissive/enforcing could cause this.

If you change to enforcing from the livecd permissive it does not set it correctly only thing that works is restorecon, setfiles, fixfiles.

I even tried copying over the rpm database from the livecd enforcing, made no difference.

There appears no way to get the labeling working automatically.

I guess this is an RPM issue.

How does RPM interact with SELINUX. When I install an rpm package, via rpm. yum what instructs the labeling to take place?

RHEL-6 rpm simply always labels unless one or more of the following is true:
1) is_selinux_enabled() from libselinux returns false
2) matchpathcon_init() on 'rpm --eval "%{_install_file_context_path}"' path fails
3) labels are specifically disabled with --nocontexts / RPMTRANS_FLAG_NOCONTEXTS API flag

Permissive vs enforcing is not considered by rpm either.

Step 2) involves looking at /etc/selinux/config contents to figure the desired policy (targeted etc) and if not found, defaults to 'targeted' contexts from /etc/selinux/targeted/contexts/files/file_contexts. In both sysreports, the entire /etc/selinux directory is missing - whether this is down to sysreport not copying it or actually not existing I dont know, but there's one possibility I guess.

A strace of the reproducer case should give us a clue what's failing and where, eg
'strace rpm -Uvh libvirt-0.10.2-15.el6.x86_64.rpm --force --nodeps' on the failing (permissive-installed) system. Some simpler package (say, "telnet") works just as well and produces less strace output.

Created attachment 685684 [details]
strace for telnet and libvirt for both permissive and enforcing installations.

That is interesting. Grep on contexts

ENFORCING.
open("/etc/selinux/targeted/contexts/files/file_contexts.subs", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/selinux/targeted/contexts/files/file_contexts", O_RDONLY) = 6
open("/etc/selinux/targeted/contexts/files/file_contexts.homedirs", O_RDONLY) = 7
open("/etc/selinux/targeted/contexts/files/file_contexts.local", O_RDONLY) = -1 ENOENT (No such file or directory)
read(6, "/)?contexts/files(/.*)?\tsystem_u"..., 4096) = 4096
read(7, "#\n#\n# User-specific file context"..., 4096) = 4096
read(6, "/)?contexts/files(/.*)?\tsystem_u"..., 4096) = 4096
read(7, "#\n#\n# User-specific file context"..., 4096) = 4096
open("/selinux/context", O_RDWR)        = 10
open("/selinux/context", O_RDWR)        = 10


PERMISSIVE
read(3, "%__file_context_path %{nil}\n", 4096) = 28
open("/etc/selinux/targeted/contexts/files/file_contexts.subs", O_RDONLY) = -1 ENOENT (No such file or directory)

ENFORCING
open("/etc/selinux/targeted/contexts/files/file_contexts", O_RDONLY) = 6

PERMISSIVE
open("", O_RDONLY)                      = -1 ENOENT (No such file or directory)

So this is the issue, thank goodness.

Livecd creates a macro.
%__file_context_path

Which disables the selinux label.

Thanks for the help, we can close this.

Okay so you already figured it out :)

There's something amiss here though, livecd shouldn't disable labeling on permissive mode, as permissive != disabled. Looking at livecd's imgcreate/kickstart.py, thats what livecd assumes:

def selinux_enabled(ks):
    return ks.handler.selinux.selinux == ksconstants.SELINUX_ENFORCING

class RPMMacroConfig(KickstartConfig):
    """A class to apply the specified rpm macros to the filesystem"""
    def apply(self, ks):
        [...]
        if not selinux_enabled(ks):
            f.write("%__file_context_path %{nil}\n")

There's the smoking gun, back to livecd-tools.

BTW looking at upstream repo, this seems to have been broken for a long time. Here's the commit where the enforcing-test originates:

commit e98a30558acc58275ee2c4469e3c4f8bea9b566f
Author: Warren Togami <wtogami>
Date:   Wed Feb 20 14:39:47 2008 -0500

    selinux --disabled fixes

[...]

 def selinux_enabled(ks):
-    return ks.handler.selinux.selinux
+    return ks.handler.selinux.selinux == ksconstants.SELINUX_ENFORCING

...and that's still in place. I guess not too many people run livecd in permissive mode ;)

Grant, could you change the last line of imgcreate/kickstart.py to:

def selinux_enabled(ks):
    return ks.handler.selinux.selinux in (ksconstants.SELINUX_ENFORCING,
                                          ksconstants.SELINUX_PERMISSIVE)

and see if that fixes things for you?

Thanks Brian, that looks good.

Created attachment 686856 [details]
patch to check for enforcing or permissive

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.