Re: [XEN PATCH] tools/xl: Add device_model_stubdomain_init_seclabel option to xl.cfg

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Tue, Jul 27, 2021 at 9:32 AM Ian Jackson <iwj@xxxxxxxxxxxxxx> wrote:
>
> Marek Marczykowski-Górecki writes ("Re: [XEN PATCH] tools/xl: Add 
> device_model_stubdomain_init_seclabel option to xl.cfg"):
> > On Mon, Jul 26, 2021 at 09:07:03AM -0400, Jason Andryuk wrote:
> > > Sort of relatedly, is stubdom unpaused before the guest gets
> > > relabeled?  Quickly looking, I think stubdom is unpaused.  I would
> > > think you want them both relabeled before either is unpaused.  If the
> > > stubdom starts with the exec_label, but it sees the guest with the
> > > init_label, it may get an unexpected denial?  On the other hand,
> > > delayed unpausing of stubdom would slow down booting.
> >
> > Some parts of the stubdomain setup are done after it's unpaused (but
> > before the guest is unpaused). Especially, PCI devices are hot-plugged
> > only when QEMU is already running (not sure why).

Thanks, Marek.

> I think the PCI hotplug involves interaction with QEMU, and providing
> only hotplug simplifies the code in libxl.  Anthony, do I have that
> righgt ?
>
> Naively, it seems to me that the security risks are limited because
> until the guest is unpaused it doesn't have the ability to do
> anything, so cannot yet mount an attack on qemu.  So I'm expecting
> that qemu is still trustworthy until the guest is unpaused.

I was looking at it from the other direction - protecting and guest
and stubdom from dom0.  The nice thing you can do is prevent dom0 from
mapping the guest's memory after the relabeling.

The relabeling placement in this patch may be okay.  The stubdom
itself is a dom0-supplied kernel & ramdisk.  So a window of time where
it's running before being relabeled isn't that big of a deal.  i.e.
instead of dom0 modifying the stubdom in that window, it could just
supply modified kernel and ramdisk initially.

Relabeling guest & stubdom prior to unpausing the guest ensures they
both have their desired labels before the guest is unpaused.  Like you
said, that seems to be the important part - both domains have their
desired label before the guest starts running.  It's when the guest
starts running that it may have sensitive contents in its memory.

I am curious if the relabeling in this patch requires more flask
permissions since the running init_label stubdom sees the paused
init_label guest.

Regards,
Jason