Snapd from the snap generate udev rules that executes snap-device-helper
from the host. In cases when the snap is newer than the package, the
new command line is rejected by the old snap-device-helper from the
package. Because the new snap-device-helper accepts old command-line,
but just ignores the extra parameters, it is safer for now to generate
rules with the old command line.
I've noticed this denial in one of my test systems:
kwi 19 10:54:52 ubuntu-2204-cryptfs kernel: audit: type=1400
audit(1713516892.723:323): apparmor="DENIED" operation="open" class="file"
profile="snap-update-ns.chromium" name="/var/lib/snapd /" pid=8425 comm="5"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Given that snap-update-ns must access mount profiles and contains code to
safely traverse a path without any symbolic links, I think the extra
permissions is acceptable.
I did not audit the code to pinpoint the exact cause.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This fixes access to /etc/apparmor.d/tunables when running from snapd snap.
When snapd snap re-executes, and uses apparmor_parser from snapd snap (those
are separate conditions), then it re-directs the parser away from host
/etc/apparmor.d and we have special code to load tunables from the host anyway.
Those tunables are themselves conditional on the conditional include syntax
that may or may not be supported by apparmor (otherwise the would be explicitly
spelled out in the template, and not dynamically expanded with custom logic).
The problem was introduced along with patch
b98e4af376 (i/apparmor: support for home.d
tunables from /etc/ (#13118)), as the case for snap-update-ns was missed, and
the default expansion is an empty string.
Regression-testing this requires that we re-package snapd snap, so the test
will come in with a separate patch as it requires somewhat more effort to
behave correctly.
This issue was identified by Maciej Borzecki.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
When running cilium under microk8s, the following denial is observed:
apparmor="DENIED" operation="create" class="net"
profile="snap.microk8s.daemon-containerd" pid=20550 comm="tc" family="alg"
sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create"
which is triggered when cilium attempts to set up network package classifier
through tc.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* interfaces/builtin/system_observe: allow listing systemd units and their properties
Allow listing systemd units and querying their properties. This enables service
plugging system-observe to obtain more information about the state of the
system. Specifically, this enables Prometheus' systemd_exporter to work.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/interfaces-system-observe: verify dbus permissions
Update the test to exercise dbus permissions to call system and get properties
of the manager and its units.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* NEWS: add a note about changes to system-observe interface
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* snap-{seccomp,confine}: rework seccomp denylist
When a denylist was introduced in PR#12849 we reached the limits
of the API of libseccomp and some things are now hard to reason
about [1]. This is mostly because what we try to do does not
match the libseccomp API very well and a slightly different
approach is probably more aligned with it's design (see also
this libseccomp issue [2] that is related to our issue).
So this commit changes the approach and instead of trying to use
a single filter the work is split into two filters:
1. explicit allow list
2. explicit deny list
and then load both filters into the kernel. The way the kernel
works is that it selects the most restrictive action.
So in the case of PR#12849:
```
~ioctl - TIOCSTI
~ioctl - TIOCLINUX
ioctl
```
For `ioctl(TIOCLINUX)` the first allow filter would pass `ioctl`
but the second deny filter would correctly deny the TIOCLINUX.
The file format of the `snap.snap.app.bin` changes to `.bin2`
and includes a proper header that would allow us to extend more
easily in the future.
The exiting tests for negative filtering got also updated so that
the deny/allow is tested via different errno numbers to ensure that
the expected filter denies the access.
The `snap-seccomp` spread test now also runs on all ubuntu releases.
This work will also allow us to remove the `global.bin` seccomp
filter in a followup PR.
[1] https://github.com/snapcore/snapd/pull/12849#discussion_r1206855700
[2] https://github.com/seccomp/libseccomp/issues/44
* snap-confine: tweak sc_seccomp_file_header struct (thanks Philip!)
* snap-confine: tweak struct init workaround in sc_apply_seccomp_profile_for_security_tag (thanks Philip)
* snap-seccomp: remove outdated comment about big endian
* snap-confine: rename sc_must_read_header_from_file->sc_must_read_and_validate_header_from_file
* snap-seccomp: rework exportBPF() to not require a temp file
Thanks to Valentin for the suggestion. Also reverts the change to
the `install-store-laaaarge` tests because there is no need for
space in /tmp anymore.
* tests: improve messae in security-seccomp deny test
* snap-confine: rename "struct stat buf" -> "struct stat stat_buf"
* snap-confine: check that filer size if multiple of sock_filter
Thanks to Valentin for the suggestion. Also adds a bunch of
C unit tests to check that the code works correctly. Sadly
C makes it hard to write this in a concise way so there is
a bit of repetition.
* snap-confine: extract must_read_and_validate_header_from_file_dies_with() helper
* snap-confine: workaround bug in gcc from 14.04
The gcc (4.8.4) in 14.04 will not compile the following code:
```
struct sc_seccomp_file_header hdr = {0};
```
and will error with:
```
snap-confine/seccomp-support.c: In function ‘sc_apply_seccomp_profile_for_security_tag’:
snap-confine/seccomp-support.c:246:9: error: missing braces around initializer [-Werror=missing-braces]
struct sc_seccomp_file_header hdr = {0};
^
snap-confine/seccomp-support.c:246:9: error: (near initialization for ‘hdr.header’) [-Werror=missing-braces]
```
to workaround this a pragma is added.
* snap-confine: check filters are not empty and keep read access to global.bin file
* tests: add details field to security-profiles and snap-seccomp spread tests
* snap-confine: move empty filter validation to sc_must_read_filter_from_file to avoid conflicts with classic snaps
* snap-{seccomp,confine}: add tests for missing seccomp profile and explicit deny has precedence to to explicit allow
* snap-confine: run make fmt
* cmd/snap-confine: make fmt again with indent 2.2.13+
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* snap-confine: Several code improvements
* snap-confine: Fix format
* snap-confine: Test fix and update deprecated SEEK_CUR
* snap-confine: Fix test
* snap-confine: Use inclusive language where possible
* snap-confine: Make woke happy until we can remove cmd/snap-seccomp-blacklist
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
Co-authored-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Ahead of introduction of CIFS workaround, generalize the names so that we use
more general language rather instead of focusing on NFS.
As a special exception the externally visible wording related to NFS is kept
intact in two places:
- The apparmor "nfs-support" file name
- The system key "nfs-home" key.
From points of view this is all an elaborate internal rename that should nto be
observable outside of snapd, apart from log messages that may no longer speak of
NFS but of remote file systems.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* interfaces/udev: add non-strict flag to snap cgroup device file
Add a non-strict=true flag to the snap's cgroup device file, to inform
snap-confine that the snap was indeed installed in a non-strict confinement mode
(eg. devmode, or classic). This supplements an earlier mechanism in which snapd
would not generate any rules tagging devices for a specific snap and can be used
as an explicit indicator to avoid mandatory device cgroup even when using bare
or core24 and later bases (as well as custom base snaps).
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* cmd/snap-confine: account for non-strict confinement when setting up device cgroup
Snaps may be installed in a non-strict confinement mode. In which case, expect
an explicit non-strict=true in the per snap /var/lib/snapd/cgroup/snap.*.file.
This replaces an earlier mechanism of implicit non-strict confinement when no
devices are assigned to the snap.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
* tests/main/security-device-cgroups-required-or-optional: update to check non-strict confinement
Update the test to check that --devmode results in a non-strict confinement
device cgroup setup.
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
---------
Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>
Allow docker to do anything with posix message queues. This may be refined
later on with more fine-grained permission. This is likely coming out of
apparmor 4.0 upgrade.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
* interfaces/desktop: allow DBus Notifications access to plasmashell
apparmor in Ubuntu 24.04 LTS introduces an AppArmor profile for KDEs plasmashell
called "plasmashell". As such, the DBus Notifications object is now implemented
by a process that has the apparmor label "plasmashell" instead of
"unconfined" (since previously it did not have an AppArmor profile).
Extend the DBus rules for /org/freedesktop/Notifications to include this new
peer label to allow snaps to send notifications as before.
Fixes part of LP: #2056696
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* interfaces/desktop-legacy: allow DBus StatusNotifierItem for plasmashell
apparmor in Ubuntu 24.04 LTS introduces an AppArmor profile for KDEs plasmashell
called "plasmashell". As such, the DBus StatusNotifierItem object is now
implemented by a process that has the apparmor label "plasmashell" instead of
"unconfined" (since previously it did not have an AppArmor profile).
Extend the DBus rules which allow access to /StatusNotifierItem to include this
new peer label to allow snaps to correctly register their app tray icons etc as
before.
Fixes the other part of LP: #2056696
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* interfaces/unity7: allow DBus access for plasmashell
apparmor in Ubuntu 24.04 LTS introduces an AppArmor profile for KDEs plasmashell
called "plasmashell". As such, the DBus Notifications, StatusNotifierItem and
dbusmenu objects are now implemented by a process that has the apparmor label
"plasmashell" instead of "unconfined" (since previously it did not have an
AppArmor profile).
Extend the DBus rules which allow access to these objects to include this new
peer label to allow snaps to correctly register their app tray icons etc as
before.
Fixes another part of LP: #2056696
Signed-off-by: Alex Murray <alex.murray@canonical.com>
---------
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* 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>
