Bug 896610 - Start windows 7 guest - internal error cannot parse sensitivity level in s0
Start windows 7 guest - internal error cannot parse sensitivity level in s0
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: livecd-tools (Show other bugs)
6.4
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: Brian Lane
Release Test Team
: Reopened
Depends On:
Blocks: 1056248
  Show dependency treegraph
 
Reported: 2013-01-17 10:53 EST by Grant Williamson
Modified: 2016-04-26 09:41 EDT (History)
19 users (show)

See Also:
Fixed In Version: livecd-tools-13.4.6-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-13 09:31:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Libvirt Stub (4.28 KB, text/plain)
2013-01-17 10:53 EST, Grant Williamson
no flags Details
libvirt log (18.38 KB, text/plain)
2013-01-17 10:58 EST, Grant Williamson
no flags Details
KS permissive (16.50 KB, application/octet-stream)
2013-01-22 04:29 EST, Grant Williamson
no flags Details
KS enforcing (16.50 KB, application/octet-stream)
2013-01-22 04:30 EST, Grant Williamson
no flags Details
sysreport permissive install (276.13 KB, application/x-bzip)
2013-01-22 09:30 EST, Grant Williamson
no flags Details
sysreport enforcing install (262.92 KB, application/x-bzip)
2013-01-22 09:30 EST, Grant Williamson
no flags Details
strace for telnet and libvirt for both permissive and enforcing installations. (271.62 KB, application/x-gzip)
2013-01-23 02:31 EST, Grant Williamson
no flags Details
patch to check for enforcing or permissive (874 bytes, patch)
2013-01-24 12:03 EST, Brian Lane
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 297193 None None None Never

  None (edit)
Description Grant Williamson 2013-01-17 10:53:18 EST
Created attachment 680298 [details]
Libvirt Stub

Description of problem:
Upgrade to RHEL 6.3 Snapshot 4.

[nl96137@oc1175023327 Desktop]$ virsh -c qemu:///system start Virtual_Client_for_Linux_Windows_7-KVM
error: Failed to start domain Virtual_Client_for_Linux_Windows_7-KVM
error: internal error Cannot parse sensitivity level in s0


Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.351.el6.alon.bz876982.v1.x86_64
libvirt-0.10.2-15.el6.x86_64
kernel-2.6.32-353.el6.x86_64
Comment 1 Grant Williamson 2013-01-17 10:53:59 EST
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.
Comment 2 Grant Williamson 2013-01-17 10:55:08 EST
Description of problem:
Upgrade to RHEL 6.3 Snapshot 4.

Should read

Description of problem:
Upgrade to RHEL 6.4 Snapshot 4.
Comment 3 Grant Williamson 2013-01-17 10:58:53 EST
Created attachment 680303 [details]
libvirt log
Comment 5 Grant Williamson 2013-01-17 11:05:52 EST
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-
Comment 6 Daniel Berrange 2013-01-17 11:25:20 EST
Can you provide output of the following command

$ ps -axuwfZ | grep libvirtd
Comment 7 Grant Williamson 2013-01-17 11:29:25 EST
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
Comment 8 Daniel Berrange 2013-01-17 11:36:01 EST
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
Comment 9 Grant Williamson 2013-01-17 11:37:35 EST
Restarting it does not fix the issue.

We have selinux running in permissive mode.

Should not be impacted.
Comment 10 Daniel Berrange 2013-01-17 11:44:25 EST
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
Comment 11 Grant Williamson 2013-01-17 11:58:58 EST
rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/sbin/libvirtd
Comment 12 Daniel Berrange 2013-01-17 12:04:07 EST
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
Comment 13 Grant Williamson 2013-01-17 12:11:42 EST
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.
Comment 14 Grant Williamson 2013-01-18 02:02:09 EST
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.
Comment 15 Jiri Denemark 2013-01-18 06:48:25 EST
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.
Comment 16 Grant Williamson 2013-01-18 07:09:41 EST
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.
Comment 17 Jiri Denemark 2013-01-18 10:55:07 EST
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.
Comment 18 Grant Williamson 2013-01-18 10:58:41 EST
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.
Comment 19 Jiri Denemark 2013-01-21 04:04:12 EST
Looks like something is wrong with rpm or selinux-policy, then.
Comment 20 Dave Allan 2013-01-21 14:07:11 EST
(In reply to comment #19)
> Looks like something is wrong with rpm or selinux-policy, then.

Reopening
Comment 21 Jiri Denemark 2013-01-22 02:59:10 EST
Reassigning to selinux-policy for further investigation. Just to be clear, with "rpm" I meant the rpm component rather than libvirt rpm packages.
Comment 22 Grant Williamson 2013-01-22 04:29:14 EST
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.
Comment 23 Grant Williamson 2013-01-22 04:29:45 EST
Created attachment 684955 [details]
KS permissive
Comment 24 Grant Williamson 2013-01-22 04:30:15 EST
Created attachment 684956 [details]
KS enforcing
Comment 25 Grant Williamson 2013-01-22 09:30:04 EST
Created attachment 685194 [details]
sysreport permissive install
Comment 26 Grant Williamson 2013-01-22 09:30:41 EST
Created attachment 685195 [details]
sysreport enforcing install
Comment 27 Grant Williamson 2013-01-22 09:33:04 EST
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.
Comment 28 Daniel Walsh 2013-01-22 10:40:04 EST
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.
Comment 29 Daniel Walsh 2013-01-22 10:44:51 EST
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.
Comment 30 Grant Williamson 2013-01-22 11:06:30 EST
Thanks for responding Dan. 
I am curious how to get the automatic labelling working again.
Can you think of anything else to try.
Comment 31 Daniel Walsh 2013-01-22 14:32:04 EST
Last time I looked, the last phase of a livecd create was to relabel the entire image, using setfiles.
Comment 32 Grant Williamson 2013-01-22 14:47:15 EST
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.
Comment 33 Daniel Walsh 2013-01-22 14:55:46 EST
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.
Comment 34 Grant Williamson 2013-01-22 15:25:56 EST
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.
Comment 35 Daniel Walsh 2013-01-22 15:51:02 EST
I guess this is an RPM issue.
Comment 36 Grant Williamson 2013-01-23 01:26:33 EST
How does RPM interact with SELINUX. When I install an rpm package, via rpm. yum what instructs the labeling to take place?
Comment 37 Panu Matilainen 2013-01-23 02:19:58 EST
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.
Comment 38 Grant Williamson 2013-01-23 02:31:50 EST
Created attachment 685684 [details]
strace for telnet and libvirt for both permissive and enforcing installations.
Comment 39 Grant Williamson 2013-01-23 03:07:46 EST
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)
Comment 40 Grant Williamson 2013-01-23 03:10:33 EST
ENFORCING
open("/etc/selinux/targeted/contexts/files/file_contexts", O_RDONLY) = 6

PERMISSIVE
open("", O_RDONLY)                      = -1 ENOENT (No such file or directory)
Comment 41 Grant Williamson 2013-01-23 03:15:30 EST
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.
Comment 42 Panu Matilainen 2013-01-23 04:48:52 EST
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.
Comment 43 Panu Matilainen 2013-01-23 04:55:42 EST
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@redhat.com>
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 ;)
Comment 44 Brian Lane 2013-01-23 18:58:22 EST
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?
Comment 45 Grant Williamson 2013-01-24 04:37:09 EST
Thanks Brian, that looks good.
Comment 46 Brian Lane 2013-01-24 12:03:13 EST
Created attachment 686856 [details]
patch to check for enforcing or permissive
Comment 48 RHEL Product and Program Management 2013-10-13 20:04:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.