* interfaces: allow ZFS vols as a block-device
ZFS is a versatile tool in managing block storage. Allowing ZFS vols
as block-devices would enable additional scenarios for snaps (like
MicroCeph) that need to deal with block storage. Specifically for
MicroCeph it could be useful for testing and development scenarios
where OSD block devices are expected without requiring actual physical
disks.
Adding the /dev/zfs ioctrl device would enable snaps to automatically
manage these volumes.
Signed-off-by: Peter Sabaini <peter.sabaini@canonical.com>
* Address review comments
Remove zfs partitions from block devs interface until we have more
clarity around bug https://bugs.launchpad.net/snapd/+bug/2033883
---------
Signed-off-by: Peter Sabaini <peter.sabaini@canonical.com>
The udev backend was not preseed aware and would always call udev reload, even
before introducing #13642 and the errors were masked. Check if the backend is
running in preseed mode and do not call udev at all.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
The bare snap has few mount points, making the use of mimics, a workaround for
creating mount points on an otherwise read-only squashfs, using a tmpfs and a
farm of directories and files for bind-mounting, is required. In the particular
case of system-packages-doc plug on a snap using the bare base snap, we need to
create and re-create /usr.
The snap-update-ns program which is responsible for the bulk of mount
manipulation, is invoked in one of two very different scenarios. Most often,
it is invoked from the "snap run" -> "snap-confine" -> "snap-update-ns", just
before the "snap-exec" hop. In this scenario it is confined with a special,
per-snap apparmor profile. This profile has so far had insufficient permissions
to perform this manipulation. A user may work around the problem by
disconnecting and re-connecting the system-packages-doc interface manually.
When this happens, the mount namespace is adjusted and kept in kernel memory
until the system re-boots. In this case snapd invokes snap-update-ns itself,
and crucially, without the apparmor sandbox.
The rationale for this behavior is that snap-update-ns is invoked by an
unprivileged user, using a setuid-root helper (snap-confine), so extra care is
warranted and snap-update-ns should have all the power it needs, but no more.
One could argue that this is highly inconsistent and they would be right. For
the moment the most conservative change is to detect this specific case and
adjust the sandbox. A more general case for a different method of setting up
the mount namespace, without the need to use mimics, or dropping the sandbox
entirely would allow us to retain precise permissions.
Fixes: https://bugs.launchpad.net/snapd/+bug/2044335
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@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>
* steam_support: generalize pressure-vessel root paths
* steam_support: convert all pressure-vessel paths to /newroot/**
Pressure Vessel is likely to change at any point, so /newroot/** allows Steam the flexibility
to do what it needs to for games to run. See discussion here: https://github.com/snapcore/snapd/pull/13489#discussion_r1454056639
* steam_support: convert LD pressure-vessel paths to /newroot/**
* steam_support: remove redundant tmpfs mount paths
Extend the network-setup-observe AppArmor snippets with the same tweak for
busctl as was added in network-setup-control.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Starting from systemd 254, busctl will attempt to bind the socket to a known
path to facilitate debugging. The change was introduced in
a0cb335816
and the path is composed of `@<hex-encoded-u64>/bus/<command>/<description>`.
Actual denial:
Feb 29 08:22:04 localhost kernel: audit: type=1400 audit(1709194924.547:213):
apparmor="DENIED" operation="bind" class="net" profile="snap.console-conf.console-conf"
pid=4504 comm="busctl" family="unix" sock_type="stream" protocol=0
requested_mask="bind" denied_mask="bind" addr="@f46ecfc1c63ae80f/bus/busctl/busctl"
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
This is a commit we've had in the Core Desktop snapd tree for a while that had not been proposed upstream.
We would like to be able to run the Steam snap on Core Desktop. We've got everything else working, so providing an implicit steam-support slot on core (specifically Core Desktop) was the last piece of the puzzle. Everything else is similar enough not to be a problem.
* interfaces: make steam-support implicit on core
* interfaces: only make steam-support implicit on desktop variants of Ubuntu Core
* interfaces: test the StaticInfo for steam-support
---------
Co-authored-by: Ken VanDine <ken.vandine@canonical.com>
Add device-cgroup-v2 sandbox feature flag which was forgotten when we landed
cgroup v2 device filtering support.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
