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
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
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
Control: severity -1 grave
Dear Maintainer,
Does this root-level access bug still affect the current
version of snapd in testing?
I do not think it befits Debian to ship a package in this
state---users expect security isolated snaps to not give
trivial root level access to their systems.
I
Thank you for reporting this bug.
This problem is something we’ve been investigating for a while internally. We
need to improve the user experience around installing snaps when we know the
sandbox confinement is not what we designed it for. Right now the consequence
of that is that large chunk
Package: snapd
Version: 2.37.3-1
Severity: important
Dear Maintainer,
I just started experimenting with snaps and noticed my (pretty vanilla)
installation is silently not confining snaps. E.g.:
$ snap install hello-world
2019-03-01T00:20:19+01:00 INFO Waiting for restart...
hello-world 6.3
6 matches
Mail list logo