If one installs the example snap hello-world and launches hello-world.evil in apparmored system the application is NOT strictly confined by default.

~$ snap run hello-world.evil
Hello Evil World!
This example demonstrates the app confinement
You should see a permission denied error next
If you see this line the confinement is not working correctly, please file a bug


My snap debug info

~$ snap debug confinement
partial

~$ snap debug sandbox-features
apparmor:             kernel:caps kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:downgraded support-level:partial
confinement-options:  classic devmode
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev:                 device-cgroup-v1 tagging

I believe the default setting should be "strict" or, at least, the package should have clear documentation on how to enable the strict mode (which, according to upstream, is the default...)

Hi,

You didn't really explain how this is a security hole. You just asked for the
default setting to be different. Downgrading.

Cheers,

Ivo

Hi,

can can verify on bullseye that this particular test case is not present
anymore:

---8<------8<------8<------8<------8<------8<------8<------8<---
$ snap run hello-world.evil

Hello Evil World!

This example demonstrates the app confinement

You should see a permission denied error next

/snap/hello-world/29/bin/evil: 9: /snap/hello-world/29/bin/evil: cannot
create /var/tmp/myevil.txt: Permission denied


$ snap debug confinement

partial


$ snap debug sandbox-features

apparmor:             kernel:caps kernel:domain kernel:file kernel:mount
kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace
kernel:query kernel:rlimit kernel:signal parser:cap-audit-read
parser:cap-bpf parser:qipcrtr-socket parser:unsafe policy:default
support-level:partial

confinement-options:  classic devmode

dbus:                 mediated-bus-access

kmod:                 mediated-modprobe

mount:                layouts mount-namespace per-snap-persistency
per-snap-profiles per-snap-updates per-snap-user-profiles
stale-base-invalidation

seccomp:              bpf-actlog bpf-argument-filtering kernel:allow
kernel:errno kernel:kill_process kernel:kill_thread kernel:log
kernel:trace kernel:trap kernel:user_notif

udev:                 tagging

---8<------8<------8<------8<------8<------8<------8<------8<---

However, I do agree with the assessment of Mattia that this should be
treated as a security issue. Users expect from snap (just like from
flatpak) that there is a process confinement in place that limits the
exposure of the filesystem access and APIs to running snaps. That is a
central design feature, and according to the principle of least
astonishment I'd expect snap in Debian to behave the same, or at least
very prominently warn about it.

Greetings,
Lee