Re: [Libguestfs] [PATCH 3/7] add_drive: Add selinuxnorelabel optional boolean.

On Thu, Feb 28, 2013 at 04:06:30PM +0000, Matthew Booth wrote: > On Thu, 2013-02-28 at 16:01 +0000, Daniel P. Berrange wrote: >> On Thu, Feb 28, 2013 at 03:52:32PM +0000, Matthew Booth wrote: >>> On Thu, 2013-02-28 at 15:49 +0000, Daniel P. Berrange wrote: >>>> On Thu, Feb 28, 2013 at 03:01:20PM +0000, Matthew Booth wrote: >>>>> Secondly, by relabelling disk images we're potentially making >>>>> them temporarily unavailable to other processes, which is >>>>> something we weren't doing before. It's possible there may be no >>>>> way round this, but if so we ought to highlight it as a major >>>>> gotcha. Is there any way we can give a file 2 different SELinux >>>>> contexts? If there were, we could leave the original untouched >>>>> and only allow our ephemeral process to access the second one. A >>>>> hard link doesn't allow this, btw. A copy is almost certainly >>>>> infeasible in the general case, but if the FS allows reflink it >>>>> might fly. Thoughts? >>>> >>>> There will never be any way to give one file multiple SELinux >>>> labels. It is explicitly rejected as a concept by security people. >>>> >>>> What I describe here though is explicitly about *not* having to >>>> make libguestfs relabel other disk images. The point is to define a >>>> policy such that libguestfs can access the other VMs' disks without >>>> any relabelling needing doing to them. >>>> >>>> Any relabelling would only be needing on any qcow2 snapshot that >>>> libguestfs has above the original disks. >>> >>> I wasn't talking about whether libguestfs or libvirt does the >>> relabelling, I was talking about the problems of any relabelling >>> happening at all to the input file. >> >> Sorry, what do you mean by "input file" here ? What files in >> particular are you worried about > > If we open an image file read-only, ideally we wouldn't modify it in any > way, including its permissions/context. If that's what you want, then you're basically saying libguestfs KVM security context needs to be allowed to read any file on the system, which is a pretty lax requirement from a security POV. It is much more secure to have libvirt/libguesfs relabel just the files which the libguesfs VM is intended to access and have a strict policy for QEMU. Daniel

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEvl8IACgkQrlYvE4MpobP4OQCgjn8NWqeX6hl740FugDQ+IK5S G24An0Uq9qQNUhPwyP+U9oVuh7SpcHp7 =IQ98 -----END PGP SIGNATURE-----