Setting SELinux label on TPM state during migration

[Stefan Berger]

On 12/19/22 07:07, Daniel P. Berrangé wrote:
> 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.

Other than generally bailing out on dynamically assigned security label assignments completely... maybe we need a table with shared filesystem types for which dynamic label assignment (from TPM migration purposes) at least 'works.'

    Stefan
>>
> 
> With regards,
> Daniel