Bug 496340
| Summary: | Creating guests where the .iso image is on a NFS share doesn't work anymore | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erik van Pienbroek <erik-fedora> | ||||
| Component: | virt-manager | Assignee: | Daniel Berrangé <berrange> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | rawhide | CC: | ajia, azelinka, berrange, crobinso, dwalsh, hbrock, markmc, petersen, quintela, tore, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-04-22 06:44:10 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 480594 | ||||||
| Attachments: |
|
||||||
|
Description
Erik van Pienbroek
2009-04-17 21:49:51 UTC
The python code should check for EOPNOTSUPP, and just continue. nfs does not support labeling, so we should not care about failure to label. 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.
Looks good to me. 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 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 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... 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 ? 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. 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. Fix has been built and tagged into dist-f11 * Tue Apr 21 2009 Cole Robinson <crobinso> - 0.400.3-7.fc11 - Only warn if selinux labeling appears to be wrong (bz 496340) *** Bug 497112 has been marked as a duplicate of this bug. *** 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 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. 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 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. (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 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 |