Setting SELinux label on TPM state during migration

[Daniel P. Berrangé]

On Mon, Dec 19, 2022 at 12:57:05PM +0100, Michal Prívozník wrote:
> Stefan,
> 
> as you saw, I'm trying to implement support for migration with TPM state
> on a shared volume. I mean, it is working when the shared volume is an
> NFS mount point because NFS does not really propagate SELinux labels,
> but rather has this 'virt_use_nfs' sebool which effectivelly allows all
> svirt_t processes to access NFS (thus including swtpm). But things get
> trickier when a distributed FS that knows SELinux properly (e.g. ceph)
> is used instead.
> 
> What I am currently struggling with is - finding the sweet spot when the
> source swtpm has let go of the state and the destination has not
> accessed it (because if it did it would get EPERM).
> 
> Bottom line - the SELinux label is generated dynamically on each guest
> startup (to ensure its uniqueness on the system). Therefore, the label
> on the destination is different to the one on the source.

AFAIR, that's not a supported migration scenario, even without swtpm.

If using dynamic label assignment, the VM label assignment MUST be
scoped to the same realm which can access the filesystem volume(s)
in use.

For non-shared filesystems, this means label assignment only needs
to be tracked per host.

For shared filesystems, which do NOT have SELinux labelling, again
label assignment only needs to be tracked per host

For shared filesytems, which DO have SELinux labelling, then label
assignment needs to be tracked across all hosts which can use that
filesystem for VM storage.

Libvirt is NOT capable of doing this tracking itself. So mgmt apps
need to tell libvirt to use a static label which they've figured
out uniqueness for globally. Libvirt can still do relabelling of
files. IOW, we'd recommend this:

  <seclabel type='static' model='selinux' relabel='yes'>

> I wonder what we can do about this.

Nothing. It is not a supportable scenario.

It is in fact a security flaw for a mgmt app to configure use of
dynamic labelling when using shared storage that honours per file
SELinux labelling. It risks have multiple VMs on different hosts
all using the same SELinux label, and loosing isolation of their
storage which is on the same shared filesystem.
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|