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

[Daniel J Walsh]

-----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-----