Instance: Relax apparmor QEMU proc rules a bit to workaround bug

[mihalicyn]

For some reason (bug in AppArmor?):
owner @{PROC}/@{pid}/cpuset r,
owner @{PROC}/@{pid}/task/@{tid}/comm rw,
rules don't work properly and forbid perfectly legal access of Qemu to proc:
[13830.493684] audit: type=1400 audit(1719481742.274:388): apparmor="DENIED" operation="open" class="file" profile="lxd-v1_</var/snap/lxd/common/lxd>" name="/proc/94213/task/94293/comm" pid=94213 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=999 ouid=0

I've noticed, that removing the "owner" keyword makes it work. Let's do this, despite it relaxes profile and makes things less secure, I can't really see any serious security impact from that change.

This only reproducible when core24 is used (new AppArmor) and ceph volume is attached to the VM.

[tomponline]

What does removing the owner part mean (in theory)?

[mihalicyn]

according to the AppArmor man:

       owner
           Specifies that the task must have the same euid/fsuid as the object being referenced
           by the permission check.

So, this rule was applied only to the files which are owned by the user who runs Qemu, but after removing it we allow Qemu to access any other files too. To be more precise, AppArmor won't disallow access to other files, at the same time generic Linux permission checks are still applied.

[tomponline]

So is @{PROC}/@{pid}/cpuset normally owned by the same user as qemu is run as? But for some reason apparmor is deny access?

Is PROC in this case the /proc?

So we are only allowing it access to files inside its own pid anyway?

This seems fine, there are a couple of other uses of @{PROC}/@{pid}/cpuset without owner in LXD already.

[mihalicyn]

So is @{PROC}/@{pid}/cpuset normally owned by the same user as qemu is run as? But for some reason apparmor is deny access?

Absolutely.

Is PROC in this case the /proc?

Yes.

So we are only allowing it access to files inside its own pid anyway?

with owner - yes, without owner we allow access to the files for other pids too. But, of course, standard Linux permission checks are still applied.

[simondeziel]

[13830.493684] audit: type=1400 audit(1719481742.274:388): apparmor="DENIED" operation="open" class="file" profile="lxd-v1_</var/snap/lxd/common/lxd>" name="/proc/94213/task/94293/comm" pid=94213 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=999 ouid=0

That's not a bug in Apparmor. The owner part of the rule means the fsuid and ouid have to be equal which they are not because QEMU tries to rename its process after it was started as a different user (uid=999 might be lxd).

[tomponline]

[13830.493684] audit: type=1400 audit(1719481742.274:388): apparmor="DENIED" operation="open" class="file" profile="lxd-v1_</var/snap/lxd/common/lxd>" name="/proc/94213/task/94293/comm" pid=94213 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=999 ouid=0

That's not a bug in Apparmor. The owner part of the rule means the fsuid and ouid have to be equal which they are not because QEMU tries to rename its process after it was started as a different user (uid=999 might be lxd).

So its a bug fix :)

[mihalicyn]

@simondeziel you are right, owner of /proc/*/task/*/comm is always root which is a bit not intuitive ;-)

That's not AppArmor bug, likely, bug was fixed in AppArmor which leads to this behavior change.

But this PR is still valid.