-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/28/2013 11:15 AM, Daniel P. Berrange wrote:
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
Seems like this might be better handled in an IRC. I don't understand the entire problem. You have process labels and file system labels. The confinement is on two parts of the label, the TYPE field and the MCS Field. MCS Labels allow your process to read file labels that match or are s0. svirt_t:s0:c1,c2 is allowed to manage svirt_image_t:s0:c1,c2 We could launch libguest with svirt_guestfs_t:s0:c1,c2 and allow it to read/only svirt_image_t:s0:c1,c2 Then I guess you want svirt_guestfs_t to be able to write to some other location, correct? -----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-----