On 08/22/2011 02:39 PM, Blue Swirl wrote:
On Mon, Aug 22, 2011 at 5:42 PM, Corey Bryant<cor...@linux.vnet.ibm.com> wrote:
>
>
> On 08/22/2011 01:25 PM, Anthony Liguori wrote:
>>
>> On 08/22/2011 11:50 AM, Daniel P. Berrange wrote:
>>>
>>> On Mon, Aug 22, 2011 at 11:29:12AM -0500, Anthony Liguori wrote:
>>>>
>>>> I don't think it makes sense to have qemu-fe do dynamic labelling.
>>>> You certainly could avoid the fd passing by having qemu-fe do the
>>>> open though and just let qemu-fe run without the restricted security
>>>> context.
>>>
>>> qemu-fe would also not be entirely simple,
>>
>> Indeed.
>>
>
> I do like the idea of a privileged qemu-fe performing the open and passing
> the fd to a restricted qemu.
Me too.
> However, I get the impression that this won't
> get delivered nearly as quickly as fd: passing could be. How soon do we
> need image isolation for NFS?
>
> Btw, this sounds similar to what Blue Swirl recommended here on v1 of this
> patch:http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02187.html
I was thinking about simply doing fork() + setuid() at some point and
using the FD passing structures directly. But would it bring
advantages to have two separate executables, are they different from
access control point of view vs. single but forked one?
We could put together an SELinux policy that would transition qemu-fe to
a more restricted domain (ie. no open privilege on NFS files) when it
executes qemu-system-x86_64.
--
Regards,
Corey
> Regards,
> Corey
>
>>> because it will need to act
>>> as a proxy for the monitor, in order to make hotplug work. ie the mgmt
>>> app would be sending 'drive_addfile:/foo/bar' to qemu-fe, which would
>>> then have to open the file and send 'drive_add fd:NN' onto the real QEMU,
>>> and then pass the results on back.
>>>
>>> In addition qemu-fe would still have to be under some kind of restricted
>>> security context for it to be acceptable. This is going to want to be as
>>> locked down as possible.
>>
>> I think there's got to be some give and take here.
>>
>> It should at least be as locked down as libvirtd. From a security point
>> of view, we should be able to agree that we want libvirtd to be as
>> locked down as possible.
>>
>> But there shouldn't be a hard requirement to lock down qemu-fe more than
>> libvirtd. Instead, the requirement should be for qemu-fe to be as/more
>> vigilant in not trusting qemu-system-x86_64 as libvirtd is.
>>
>> The fundamental problem here, is that there is some logic in libvirtd
>> that rightly belongs in QEMU. In order to preserve the security model,
>> that means that we're going to have to take a subsection of QEMU and
>> trust it more.
>>
>>> So I'd see that you'd likely end up with the
>>> qemu-fe security policy being identical to the qemu security policy,
>>
>> Then there's no point in doing qemu-fe. qemu-fe should be thought of as
>> QEMU supplied libvirtd plugin.
>>
>>> with the exception that it would be allowed to open files on NFS without
>>> needing them to be labelled. So I don't really see that all this gives us
>>> any tangible benefits over just allowing the mgmt app to pass in the FDs
>>> directly.
>>>
>>>> But libvirt would still need to parse image files.
>>>
>>> Not neccessarily. As mentioned below, it is entirely possible to
>>> enable the mgmt app to pass in details of the backing files, at
>>> which point no image parsing is required by libvirt. Hence my
>>> assertion that the question of who does image parsing is irrelevant
>>> to this discussion.
>>
>> That's certainly true.
>>
>> Regards,
>>
>> Anthony Liguori
>
>
>
