Can we change ownership in tpm2-udev.rules?

[ghost]

Can this entry:

KERNEL=="tpmrm[0-9]*", TAG+="systemd", MODE="0660", OWNER="tss", GROUP="tss"

Be changed to:

KERNEL=="tpmrm[0-9]*", TAG+="systemd", MODE="0660", GROUP="tss"

Because root needs write access as well otherwise processes like for example systemd-cryptenroll will require CAP_DAC_OVERRIDE just to be able to write to that node.

[williamcroberts]

The proper fix would be to add group tss to the supplemental group list of the service that needs access.

Root, by default has a saturated capability set, so unless something is twiddling with your capability set, root has cap dac override. The only time you would see it fail is if something dropped that from the capability set or an LSM is in place. But again, use DAC controls (supplemental groups) and you should avoid the issue.

[ghost]

systemd-cryptenroll is not a service though, and yes SELinux exposed this issue: https://github.com/DefenSec/dssp5/commit/cb004093259ad68c9d8340f3695761ba419263d3

I dont see why tpm2-tss should claim full ownership of /dev/tpmrm

[AndreasFuchsTPM]

@williamcroberts what shall we do with this one ? Candidate for 4.0 ?

[williamcroberts]

systemd-cryptenroll is not a service though, and yes SELinux exposed this issue: https://github.com/DefenSec/dssp5/commit/cb004093259ad68c9d8340f3695761ba419263d3

Ahh, yes, but the user could just have group tss as a workaround.

I dont see why tpm2-tss should claim full ownership of /dev/tpmrm

I guess it doesn't, since tpm stays user root, going through the resource manager interface shouldn't require user not root. Correction: tpm driver itself requires user "tss".

But I don't see why user root cannot use the rm interface.