Bug 496340 - Creating guests where the .iso image is on a NFS share doesn't work anymore
Creating guests where the .iso image is on a NFS share doesn't work anymore
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
: 497112 (view as bug list)
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
 
Reported: 2009-04-17 17:49 EDT by Erik van Pienbroek
Modified: 2011-11-17 01:51 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-22 02:44:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Don't error if labelling fails, or labelling appears to be incorrect (2.20 KB, text/plain)
2009-04-20 14:19 EDT, Cole Robinson
no flags Details

  None (edit)
Description Erik van Pienbroek 2009-04-17 17:49:51 EDT
Hi,

When using the latest virt-manager on rawhide to create a guest I wasn't able to complete the wizard. This seems to be caused by a SELinux issue. The .iso image which I selected resides on a (CentOS 5) NFS share. With earlier versions of virt-manager I also got SELinux issues (bug 493692), but could work around that by temporary disabling SELinux. With the latest version of virt-manager this isn't even possible anymore as the wizard refuses to complete until the user has manually fixed the SELinux permissions (even when SELinux is set to 'permissive' mode).

This is the complete error that virt-manager spits out when trying to complete the wizard:

Unable to complete install '<type 'exceptions.ValueError'> Unable to fix install volume SELinux labelling: [Errno 95] Bewerking wordt niet ondersteund
Please run 'chcon system_u:object_r:virt_content_t:s0 /mnt/fileserver/en_winXP_Pro_x86_build2600_ISO.iso' manually and retry installation
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1495, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in _do_install
    self._create_devices(meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 601, in _create_devices
    disk.setup(progresscb)
  File "/usr/lib/python2.6/site-packages/virtinst/VirtualDisk.py", line 608, in setup
    self.setup_security_context()
  File "/usr/lib/python2.6/site-packages/virtinst/VirtualDisk.py", line 711, in setup_security_context
    ("Please run 'chcon %s %s' manually and retry installation" % (wantLabel, self.path)))
ValueError: Unable to fix install volume SELinux labelling: [Errno 95] Bewerking wordt niet ondersteund
Please run 'chcon system_u:object_r:virt_content_t:s0 /mnt/fileserver/en_winXP_Pro_x86_build2600_ISO.iso' manually and retry installation
'


The message 'Bewerking wordt niet ondersteund' is Dutch for 'Operation not supported'.

Could an extra check be added to virt-manager so that this message doesn't popup when SELinux is set to 'permissive' mode?
Comment 1 Daniel Walsh 2009-04-20 09:01:04 EDT
The python code should check for EOPNOTSUPP, and just continue.

nfs does not support labeling, so we should not care about failure to label.
Comment 2 Cole Robinson 2009-04-20 14:19:14 EDT
Created attachment 340400 [details]
Don't error if labelling fails, or labelling appears to be incorrect

I don't think we should care about failure to label at all. We will never be able to fully predict what will and won't work, so there will always be false positives with this stuff.

The attached patch changes the raised exceptions to just be warnings. If the user is running virt-install, these will be shown in the terminal. virt-manager users won't see them (except in the logs).

At a later date when this code is a bit more robust, we can probably make these warnings interactive, e.g. 'Could not correctly label media. Do you still want to continue?' or similar. But I think the above patch is sufficient for now.
Comment 3 Daniel Walsh 2009-04-20 14:45:42 EDT
Looks good to me.
Comment 4 Daniel Berrange 2009-04-20 14:52:53 EDT
This isnt about a false positive though. In the scenario where the ISO is on NFS, SELinux is enforcing, and the label is wrong, we can guarentee it won't work. We absolutely should tell the user this, which is what the code was trying todo, otherwise they'll just get a failure from QEMU.

What's misleading here is that we are telling the user to run 'chcon', but this won't work on NFS because it doesn't support labelling. There's not much the user can do here, they're basically doomed at this point, unless they can set a mount context for the whole NFS volume
Comment 5 Daniel Walsh 2009-04-20 14:58:05 EDT
Well we can allow svirt to read nfs_t, 

Currently you need to turn on a boolean virt_use_nfs, which will give svirt_t the ability to read/write any nfs files systems without a context mount.

setsebool -P virt_use_nfs 1
Comment 6 Daniel Berrange 2009-04-20 15:05:22 EDT
That all said, the current patch I have in the RPM is wrong because it is raising a ValueError even when SELinux is permissive. We need to make it check whether SELinux is enforcing, or permissive. Unfortunately the libvirt capabilities XML for security model doesn't tell us this for the host as a whole, we only get told 'enforcing' info on a per-domain basis. So we need to extend libvirt security model capabilities to include whether the model is enforcing or not first...
Comment 7 Daniel Berrange 2009-04-20 15:07:21 EDT
WRT comment #5, is there any way to test whether a specific SELinux domain can read/write a specific SELinux file context, without actually having the program doing the test run as the SELinux domain in question ?
Comment 8 Daniel Walsh 2009-04-20 15:20:25 EDT
Short answer is no.  Theoretically you could if you "Knew" what the security policy that was loaded, and you could check all of the paths up to the directory in question for search/getattr, then checked the access you needed, then searched the policy for any constraints you might have violated.

So I think it is best we don't go there.

As I have said before, this same problem exists for rootsquash nfs shares.


You need to check permissive mode at the time of the failure, not at the time that libvirt was started.

The chcon suggestion should be removed, though since this will probably not help.
Comment 9 Cole Robinson 2009-04-20 15:40:04 EDT
I agree that the capabilities xml needs to be extended to show enforcing vs. permissive. But, since we lack that functionality at the moment, we aren't in a position to tell the user 'this will fail' with 100% accuracy (also accounting for the above mentioned virt_use_nfs switch, or future policy changes), so I think just logging the warning is the best we can do at this stage for F11.

At worst, the end result will be the same as its always been (qemu failing mysteriously) but with more info in the logs.

If people agree with that, I'll drop the 'chcon' suggestion and commit.
Comment 10 Mark McLoughlin 2009-04-22 02:44:10 EDT
Fix has been built and tagged into dist-f11

* Tue Apr 21 2009 Cole Robinson <crobinso@redhat.com> - 0.400.3-7.fc11
- Only warn if selinux labeling appears to be wrong (bz 496340)
Comment 11 Cole Robinson 2009-04-22 09:31:59 EDT
*** Bug 497112 has been marked as a duplicate of this bug. ***
Comment 12 Tore Anderson 2009-10-24 07:16:00 EDT
I'm also affected by this bug (in a fully updated F11).  The setsebool fix command doesn't help, but adding context="system_u:object_r:virt_content_t:s0" to the options column in /etc/fstab for the NFS file system in question and remounting does.

I can imagine it's pretty common to want to boot from images on networked filesystems (for instance we have a NFS share with ISO images for all kinds of operating systems at work, and at home I generally download large files to a NAS appliance instead of straigt to my workstation).  Therefore the sensible default setting is for this to be allowed, in my opinion.  At least I fail to understand what kind of security hole is closed by disallowing booting from images on remote filesystems...?

Tore
Comment 13 Daniel Walsh 2009-10-26 11:02:11 EDT
It is not boot that is the problem it is write.  If I allow a confined qemu image to write to nfs disks, and one becomes cracked into. I allow all my nfs shares to be attacked by this image.
Comment 14 Tore Anderson 2009-10-26 12:38:55 EDT
I'm not entirely convinced.  I mean, you could do a s/nfs (disks|shares)/local filesystems/g on your statement and it would still make as much sense, yet I have no difficulty using image files in my home directory with the default policy?

And it would not be sufficient to simply crack into the guest OS, you'd have to escape out of it and into the non-virtualised OS instance that actually have the NFS share(s) mounted, I think?  (And at that point most bets are off...)

Anyway - it is read-only access I think is needed most commonly.  Is it possible to make the default policy allow for that, I wonder?

Tore
Comment 15 Daniel Walsh 2009-10-26 14:04:43 EDT
The hole idea of svirt is to stop

"And it would not be sufficient to simply crack into the guest OS, you'd have to
escape out of it and into the non-virtualised OS instance that actually have
the NFS share(s) mounted, I think?  (And at that point most bets are off...)"

This has happened in Zen and I am sure it has happened with vmware, and I WILL happen with QEMU.  When it does we want to have svirt to prevent the attack from escalating. 

I look at every qemu process as a hostile process not all other qemu procesess and images and to the host system.  So I want to prevent it from doing anything unexpected or evil as much as I can.
Comment 16 Mark McLoughlin 2009-10-29 08:00:59 EDT
(In reply to comment #12)
> I'm also affected by this bug (in a fully updated F11).  The setsebool fix
> command doesn't help, but adding context="system_u:object_r:virt_content_t:s0"
> to the options column in /etc/fstab for the NFS file system in question and
> remounting does.

Does libvirt-0.6.2-19.fc11 from updates-testing help? See bug #517157
Comment 17 Tore Anderson 2009-10-29 15:49:49 EDT
Mark,

yes, it does, I can now boot from ISOs on NFS mounts.  I can even do so when virt_use_nfs is off, not sure if that's intentional or not?  But at least no obscure "domain didn't show up failures" so it's a clear improvement for me.

Tore

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