When using apparmor_parser from the host, pin the supported policy to ABI 3.0
if one is present on the host. This way even on distributions with Apparmor
4.0, we get the behavior of 3.0 and the meaning of our apparmor profiles stays
the same. At the same time apparmor 2.0 distributions remain unchanged.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* client,cmd/snap: introduce --user, --system and --users switches for snap service operations
* client,o/servicestate: move Scope/UserSelection to client for reuse in client
* client,cmd/snap: improve handling of user and scope args
* NEWS: update news to reflect that we now support user daemons in start/stop/restart
* cmd/snap: some review feedback on allowed input
* t/main/services-user: add additional user to verify services are correctly affected
* cmd/snap: do not allow --system --user together, do not allow --users with =all
* tests,cmd: use --users=all in test, dont mark --users optional, enforce a value for it, add case for --system --users=all in spread test
* cmd/snap: add a comment for unreachable code, and correct a couple of messages
This commit updates snapd's useage of strace to use the new
--gid/--uid cmdline options instead of -u to work around an
issue that causes issues if strace is statically linked (due
to libnss).
Signed-off-by: Tony Espy <espy@canonical.com>
* dirs: add directory location for storing cgroup policy related flags
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: introduce cgroup policy flag for self managed device cgroup
Some snaps, due to their interfaces, are allowed to self manage the device
cgroup. In this case, the assumption was to not emit any rules at all, and
instead rely on the implicit behavior that no rules means no matching devices
and hence no device cgroup filtering. However, with introduction of a device
cgroup by default for all snaps on core24 onward, regardless of any assigned
devices, we need a separate source of information to indicate that a snap can do
self management.
The patch introduces a policy flags under /var/lib/snapd/cgroup, named
snap.<name>.device, eg.
/var/lib/snapd/cgroup/snap.docker.device, which provides a hints for
snap-confine to not set up a device cgroup filtering for apps.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: support snaps which self-manage device cgroup
Support for snaps for which policy explicitly states that the device cgroup is
self-managed. The typical use case is container like technologies. In such
scenario, there will be a device cgroup configuration file at a known location
which got generated by snapd whenever the relevant interface state changed.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: spread test
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: drop base from bases exempt from mandatory device cgroup
We have confirmed that there are no snaps which (ab)use system files and use
bare base to obtain access to devices. As such, the bare base can be dropped
form the list of bases exempt from mandatory device cgroup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: remove snap devices file when removing the snap
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: consistent use of fs.ErrNotExist
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: leave comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: tweak return path
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: improve managed device cgroup unit tests, verify calls to udevadm
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* NEWS: leave a note about mandatory device cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: tweak comments
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: always write the device file
Always write the device file which serves as a synchronization point between
snap-confine and the snapd udev backend.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/libsnap-confine-private: add helper for waiting for a file to show up
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: make cgroup device file mandatory
Make the per-snap /var/lib/snapd/cgroup/snap.*.device file mandatory, such that
it can be used as a synchronization point between snapd calling Setup() of
relevant security backends and the execution path in snap-confine.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-mgmt: do cleanup of /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: declare /var/lib/snapd/cgroup
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: use the file wait helper
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* packaging: create cgroup directory
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-self-manage: update file check
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-required-or-optional: update test to verify device file
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/udev: refactor reloading
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: move device cgroup mode selection to a helper
Extract device cgroup mode selection into a helper function.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
When no devices are tagged for the given snap, snap-confine will not put the
current process under a device cgroup. This may lead to the snap having access
to more devices than allowed by its connected interfaces. Example case when this
happens is input devices, where AppArmor is not expressive enough and selective
access is implemented using a device cgroup. On top of this, abusing
system-files may accidentally allow a process to access a given device without
additional mediation through device cgroup.
Moving forward we will set up device access mediation through cgroups for snaps
always, unless the snap is using one of the well-known bases where the old
behavior will be preserved for the sake of staying backwards compatible. Right
now, snaps using bases:
- core, core16, core18, core20, core22
- base
will be exempt from the new behavior. However, snaps using base core24 onward,
or other bases will be a subject to mandatory device cgroup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* o/devicestate: use default recovery system that is independent of seeded systems
* o/devicestate: use default recovery system from state when rebooting without a specified label
This change has the side effect of enabling users to reboot into any
recovery system with "snap reboot --recover", regardless if it is the
default or the most recently seeded system.
* o/devicestate: expose default-recovery-system via DeviceManager.Systems()
* daemon, client: expose default-recovery-system via the systems api
* c/snap: update help text for reboot to match new default-recovery-system behavior
* c/snap: add default-recovery-system to notes section in recovery cli output
* o/devicestate: prevent removal of default recovery system
* o/devicestate, daemon: use default-recovery-system for factory-reset mode as well
* c/snap: update help text to mention that default recovery system is used for factory-reset
* o/devicestate: make a newly seeded system the default-recovery-system
* o/devicestate: add helper to DeviceManager for getting the default-recovery-system
* o/devicestate: use default-recovery-system for install mode as well
* c/snap: correct "snap reboot" help text
* o/devicestate, daemon: store more information for default-recovery-system in state to match seeded systems
* cmd/snap: tweak default recovery system notes
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* o/devicestate: make sure that we're storing correct type when setting default-recovery-system, extend tests
Make sure we're storing the right type when setting default-recovery-system.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Co-authored-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Create mount units for /lib/{modules,firmware} that are run before
kernel modules get loaded. The directories mounted have been built on
kernel/components installation in
/var/lib/snapd/kernel/<snap_name>/<revision>. This is done only for UC
or hybrid systems, which must have a snap kernel installed.
To find out which kernel snap is currently active, the snap file
backing /run/mnt/kernel is found and the snap name and revision is
extracted from it.
* many: allow building without bolt using nobolt tag
Bolt is an abandoned project. Upstream is not accepting any patches.
Debian has three versions of bolt, none of which build on riscv64 due to
the lack of appropriate architecture tags.
In Debian, bolt is not built from the vendored package but instead from
the distribution package, one of three in the archive, each capturing a
different, outdated and differently patched fork.
Fortunately, bolt is not really heavily used in snapd. While we try to
address the issue regarding bolt and riscv64, we can continue to build
snapd on riscv64 without the ability to store information only used by
command-not-found helpers.
Allow advisor to fail with advisor.ErrNotSupported when snapd is built without
bolt support. Tests for the store, overlord package and the "snap advise"
command are adjusted to skip certain tests when that error is returned.
Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010686
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* advisor: adjust error message
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* tests: run unit tests for nobolt build tag
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* packaging: drop bolt from debian dependencies
With the ability to build snapd without bolt support, we can drop the patch
responsible for using non-forked bolt. Bolt is really only needed by the
advisor package, which is used and consumed as a command-not-found data set.
None of that is effective on Debian, making maintenance easier.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* packaging: do not use bolt on Debian
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
---------
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* c/snap-bootstrap: lift requirement for fde-setup hook for single-boot-install
* tests/nested/manual/uc20-install-in-initrd: test various systems that support single-boot install
* c/snap-bootstrap: add test for single-boot install without a fde-setup hook
* tests/nested/manual/uc20-install-in-initrd: use "not" rather than "!" in spread test
* daemon: add offline field to remodeling JSON payload
* client, cmd/snap: add offline boolean option for remodeling to client and cli interface
* daemon: make snap files optional in the "multipart/form-data" remodel api
* tests/nested/manual/remodel-offline: add variants to test different combinations of installed/local snaps/assertions
* client: update comment on RemodelWithLocalSnaps to mention not contacting the store
* c/snap: remove unneeded var declaration
* tests/nested/manual/remodel-offline: clarify section that acks/adds the validation set assertion
* tests/nested/manual/remodel-offline: fix shellcheck warning on test's -a flag
* client: verify that normal (online) remodel does not set offline field in JSON payload
