Bug#923500: snapd: non-classic snap not confined

[Michael Vogt]

Just a quick update - we looked at this and we think the apparmor
support in Debian is sufficient to enable it in snaps by
default.

This is being worked on in https://github.com/snapcore/snapd/pull/9936
and once that lands I will upload to Debian. The goal is within this
week.

In addition to the spread tests we manually validated some key snaps
and did not see regressions.

With that upload we can close this bug because snaps are confined on
Debian. Snaps will see the read only version of the "base" snap
(e.g. core or core20) and only what access is granted via snap
"interfaces". 

Cheers,
 Michael

Bug#923500: snapd: non-classic snap not confined

[intrigeri]

Hi,

James Henstridge (2021-02-16):
> 2. As for why Debian is not being considered for "full" support,
> I suspect this is down to the out-of-tree patches to enable access
> control for unix domain sockets. This will likely resolve itself
> when snapd moves to use the new AppArmor 3.0 network features (which
> does not rely on out of tree patches).

FTR, according to Jamie Strandboge [1], even with AppArmor 3 some
network features are missing until support is added to the upstream
kernel:

Jamie Strandboge  (Mon, 5 Oct 2020 12:42:50 -0500):
> AppArmor 3 allows use of networkv8 rules (ie, what is in the upstream
> kernel) so apparmor 3 in Debian would allow for this to work.
>
> The upstream kernel does not yet support AF_UNIX rules, so anonymous
> sockets, abstract sockets and dbus won't be available. Work has picked
> up to get this into the upstream kernel (perhaps 5.11).

[1] https://bugs.debian.org/712451#126

Cheers!

Bug#923500: snapd: non-classic snap not confined

[James Henstridge]

I work on some parts of snapd at Canonical, so thought I'd weigh in.
I've got a few of points to add:

1. In the "snap debug confinement" output, it says
"policy:downgraded".  This indicates that snapd didn't detect enough
AppArmor features to enforce the full "strict confinement" sandbox, so
it switches to a permissive policy.  This was done because the
generated policies would sometimes malfunction on such systems.

We do have a system to prevent the downgrade on some systems where
we've verified that the sandbox behaves correctly:

https://github.com/snapcore/snapd/blob/cc398c14fe13c70d14b9cb2eef9873cd4b8eda1e/interfaces/apparmor/backend.go#L614-L629

I suspect current Debian probably meets this standard, so we should
add it to the exceptions list.

2. As for why Debian is not being considered for "full" support, I
suspect this is down to the out-of-tree patches to enable access
control for unix domain sockets.  This will likely resolve itself when
snapd moves to use the new AppArmor 3.0 network features (which does
not rely on out of tree patches).

3. Even on systems where the full strict confined sandbox is enabled,
acess to the root directory is granted in the base template:

https://github.com/snapcore/snapd/blob/3173439195f62eacd6493cd49f257480811ed7a7/interfaces/apparmor/template.go#L444-L445

Note however that the root directory as seen within a snap's sandbox
is not the same as the root directory of the host system.  Instead,
the contents of the "base snap" used by the snap.  In the case of the
"hello-world" snap, the base is "core".  For example, this is the
output on my system:

james@scruffy:/$ ls
bin   cdrom  etc   liblib64   lost+found  mnt  proc  run   snap  sys  usr
boot  devhome  lib32  libx32  media   opt  root  sbin  srv   tmp  var
james@scruffy:/$ snap run --shell hello-world
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

james@scruffy:/$ ls
bin   dev  home  lib64meta  opt   root  sbinsrv  tmp  var
boot  etc  lib mediamnt   proc  run   snapsys  usr  writable

You should find that the non-AppArmor parts of the sandbox are still in effect.

James.