Bug 614338 - setting Security Model=None take no effect without any prompt/warning
setting Security Model=None take no effect without any prompt/warning
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Cole Robinson
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-14 03:35 EDT by dyuan
Modified: 2011-05-19 09:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:46:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0637 normal SHIPPED_LIVE virt-manager bug fix and enhancement update 2011-05-18 13:55:47 EDT

  None (edit)
Description dyuan 2010-07-14 03:35:41 EDT
Description of problem:

Guest is shutoff, select 'None' option in Model droplist, apply it.
Then start the guest, the Model will back to selinux both in virt-manager and xml.

Maybe it will take effect when SELINUX=enforcing in /etc/selinux/config, but there should be a prompt when the change take no effect.


Version-Release number of selected component (if applicable):
virt-manager-0.8.4-6.el6

How reproducible:
always

Steps to Reproduce:
1. Prepare an VM which is not running.
2. launch virt-manager.
3. Select the existing VM, then "open" -> "details" -> "Overview" -> "Security"
4. Select "None" option in Model droplist, then apply it.
5. Start the vm
  
Actual results:
the Model will back to selinux both in virt-manager and xml.

Expected results:


Additional info:

[Wed, 14 Jul 2010 15:15:24 virt-manager 3916] DEBUG (domain:1680) Changing seclabel with model=selinux t=dynamic label=
[Wed, 14 Jul 2010 15:15:24 virt-manager 3916] DEBUG (libvirtobject:150) Redefining 'rhel6' with XML diff:
--- Original XML 
+++ New XML 
@@ -47,4 +47,4 @@
       <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
     </video>
   </devices>
-</domain>
+<seclabel model="selinux" type="dynamic"><label></label></seclabel></domain>

[Wed, 14 Jul 2010 15:15:24 virt-manager 3916] DEBUG (libvirtobject:142) Redefinition request XML was no different, redefining anyways


[Wed, 14 Jul 2010 15:15:44 virt-manager 3916] DEBUG (domain:1680) Changing seclabel with model=None t=dynamic label=
[Wed, 14 Jul 2010 15:15:44 virt-manager 3916] DEBUG (libvirtobject:142) Redefinition request XML was no different, redefining anyways
[Wed, 14 Jul 2010 15:15:44 virt-manager 3916] DEBUG (libvirtobject:142) Redefinition request XML was no different, redefining anyways
Comment 2 RHEL Product and Program Management 2010-07-15 10:54:22 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 Cole Robinson 2010-09-29 14:28:17 EDT
Pretty sure this is a libvirt limitation, there isn't any way in the XML to specify 'don't use any security model for this guest'. Reassigning to libvirt
Comment 5 Cole Robinson 2011-01-12 13:10:38 EST
Patches have been sent upstream:

https://www.redhat.com/archives/libvir-list/2011-January/msg00468.html

However they are dependent on changes that have gone in past 0.8.7 which probably shouldn't be backported to 6.1. So since this isn't a customer request, I think it might be best push this off to 6.2.
Comment 6 Daniel Berrange 2011-01-12 13:29:53 EST
NB, we explicitly didn't allow any way to selectively disable security on individual domains in sVirt. One single unconfined guests running on a host, can compromise the security protection of all other guests. No guest should be allowed to run unconfined, if SELinux is set to enforcing. While if it is permissive, then there's no benefit to selectively allowing unconfined guests, because all are effectively unconfined.
Comment 8 Cole Robinson 2011-01-13 10:54:16 EST
Okay, since the general premise has been rejected upstream, reassigning back to virt-manager. The UI should make it clear that security can not be disabled.
Comment 9 Daniel Berrange 2011-01-13 11:02:26 EST
Arguably libvirt should still raise an explicit error if model=none was requested in XML, instead of silently using model=selinux anyway.
Comment 10 Eric Blake 2011-01-13 11:04:50 EST
Cole's patches to convert from a free-form string to a checked enum would help in that regard.
Comment 11 Cole Robinson 2011-01-13 12:14:07 EST
I'm pretty sure libvirt does raise an error if model='none', in the SecurityVerify step. The way virt-manager was trying to disable security was by just removing the entire <seclabel>, which has never worked.
Comment 12 Cole Robinson 2011-01-13 12:25:42 EST
Fixed upstream:

http://hg.fedorahosted.org/hg/virt-manager/rev/550da554b0ac
Comment 13 Cole Robinson 2011-02-24 11:50:18 EST
This is already fixed in virt-manager-0.8.6-1
Comment 15 zhanghaiyan 2011-03-02 03:52:49 EST
Verified this bug PASS with virt-manager-0.8.6-2.el6.noarch

Open virt-manager, double click on a guest, select view->Details, could see 'none' selection for security model is removed and only 'selinux' for it.
Comment 16 mliu 2011-04-18 01:32:44 EDT
Verified this bug PASS with virt-manager-0.8.6-3.el6.noarch
Comment 17 errata-xmlrpc 2011-05-19 09:46:18 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0637.html

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