Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 1 commit into from
Jun 27, 2024
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions lxd/apparmor/instance_qemu.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,8 +41,8 @@ profile "{{ .name }}" flags=(attach_disconnected,mediate_deleted) {
/{,usr/}bin/qemu-system-* mrix,
/usr/share/qemu/** kr,
/usr/share/seabios/** kr,
owner @{PROC}/@{pid}/cpuset r,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

owner @{PROC}/@{pid}/task/@{tid}/comm rw,
@{PROC}/@{pid}/cpuset r,
@{PROC}/@{pid}/task/@{tid}/comm rw,
{{ .rootPath }}/etc/nsswitch.conf r,
{{ .rootPath }}/etc/passwd r,
{{ .rootPath }}/etc/group r,
Expand Down
Loading