Zygmunt Bazyli Krynicki 9baeee4891 i/apparmor: allow snap-update-ns to traverse to /var/lib/snapd (#13858) ...

I've noticed this denial in one of my test systems:

  kwi 19 10:54:52 ubuntu-2204-cryptfs kernel: audit: type=1400
  audit(1713516892.723:323): apparmor="DENIED" operation="open" class="file"
  profile="snap-update-ns.chromium" name="/var/lib/snapd /" pid=8425 comm="5"
  requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Given that snap-update-ns must access mount profiles and contains code to
safely traverse a path without any symbolic links, I think the extra
permissions is acceptable.

I did not audit the code to pinpoint the exact cause.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

2024-04-24 11:27:52 +02:00

..

apparmor_test.go

many: move AA profile operations to sandbox/apparmor

2022-04-22 09:53:51 +03:00

apparmor.go

many: fix formatting w/ gofmt 1.19

2023-01-16 14:23:11 +01:00

backend_test.go

many: generalize wording of NFS workaround (#13758)

2024-04-04 19:22:17 +02:00

backend.go

i/apparmor: add missing expansion for s-u-n template (#13853)

2024-04-24 11:27:52 +02:00

export_test.go

many: reinstate vendored apparmor (#12543)

2023-04-21 10:27:28 +02:00

spec_test.go

many: introduce SnapAppSet for use in security backends (#13574)

2024-02-19 11:57:42 +01:00

spec.go

many: introduce SnapAppSet for use in security backends (#13574)

2024-02-19 11:57:42 +01:00

template_vars.go

add SNAP_INSTANCE_DESKTOP template var and use it

2020-08-14 20:44:24 +00:00

template.go

i/apparmor: allow snap-update-ns to traverse to /var/lib/snapd (#13858)

2024-04-24 11:27:52 +02:00