The SELinux reference policy has a new set of access vectors for watch*. The
support in core policy landed in
https://github.com/fedora-selinux/selinux-policy/pull/546 on 07.02.2021. Present
in selinux-policy 3.14.7 in Fedora 34 and Rawhide.
Snapd sets up /var/lib/snapd/dbus-1/services to be watched by the system dbus.
However, dbus trying to watch those directories triggers new watch permissions
to be checked. The snappy.te policy does not allow this access, thus on Rawhide
dbus fails like this:
systemd[1]: Starting D-Bus System Message Bus...
dbus-broker-launch[7728]: ERROR dirwatch_add @ ../src/util/dirwatch.c +122: Permission denied
dbus-broker-launch[7728]: launcher_load_service_dir @ ../src/launch/launcher.c +763
dbus-broker-launch[7728]: launcher_load_services @ ../src/launch/launcher.c +978
dbus-broker-launch[7728]: launcher_run @ ../src/launch/launcher.c +1306
dbus-broker-launch[7728]: run @ ../src/launch/main.c +152
dbus-broker-launch[7728]: main @ ../src/launch/main.c +178
dbus-broker-launch[7728]: Exiting due to fatal error: -13
systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Triggering the following denial:
type=AVC msg=audit(1613393808.456:478): avc: denied { watch } for
pid=7728 comm="dbus-broker-lau"
path="/var/lib/snapd/dbus-1/system-services" ...
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:snappy_var_lib_t:s0
tclass=dir permissive=0
Fixes: https://bugs.launchpad.net/snappy/+bug/1915642
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
When PATH contain spaces, which is a really bad idea anyway, the export will
most likely set it to a value up to the first space. Use quoting to prevent
that.
Note, shellcheck does not complain about that, but try this:
sh-5.1$ export foo=foo bar baz
sh-5.1$ echo $foo
foo
sh-5.1$ export foo="foo bar baz"
sh-5.1$ echo $foo
foo bar baz
sh-5.1$
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Some distros, eg. CentOS 7 do not have /tmp on tmpfs. Because of this, the
policy rules for tmpfs are not effective and the following denial can be
observed when disconnecting the x11 interface (which mounts /tmp/.X11-unix from
the host):
type=AVC msg=audit(1606220902.660:1383): avc: denied { rmdir } for
pid=28575 comm="snap-update-ns" name=".X11-unix" dev="sda2"
ino=17552915
scontext=system_u:system_r:snappy_mount_t:s0
tcontext=system_u:object_r:tmp_t:s0
tclass=dir permissive=1
We need to extend the policy to explicitly allow poking generic tmp_t files and
directories.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* Testing new fedora 33 image
* packaging/fedora: align with Fedora source tree
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* Skip tests on f33 due to it uses cgroupv2
* data/selinux: account for s-c unmounting things
The snap-confine helper unmounts some locations which are actually a tmpfs with
a different label. Update the policy to allow that.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* tests/main: Fedora 33 nsswitch uses resolved first for host resolution
Make sure that we also stop or flush resolved caches when disabling blocking DNS
or clearing resolve.conf.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* tests/main/snap-network-errors: tweak to account for older systemd versions
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* spread: Fedora 31 is EOL on 24.11
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Co-authored-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
We stumbled on the fact that snapd cannot effectively kill stuck hooks
while debugging other permissions errors.
Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
The sudo secure_path setting resets the PATH to some predefined value for
commands executed under sudo. We have tried to workaround
https://bugzilla.redhat.com/show_bug.cgi?id=1691996 by trying to extend the
secure_path in a drop in conf files. This approach does not work for 2 reasons:
- the file is incorrectly named
- secure_path is a string and += append only works on lists (eg. env_keep)
Since there is no clear way to fix the problem other than talking with
distributions, drop the workaround. We can always revert the patch when needed.
Fixes: https://bugs.launchpad.net/snapd/+bug/1882215
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Add interface definitions for listing and reading files and directories under
/var/lib/snapd.
Allow system dbus to read snappy_var_lib_t. This enables the dbus-daemon process
to service definition files under /var/lib/snapd/dbus.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The fwupd_search_cache() interface template is not defined on RHEL7.
In theory we should be able to use the `optional_policy(..)` block to capture
that, but based on investigation, the optional block is not correctly handled
when expanding the policy in kernel policy language. After m4 preprocessing is
done, the interface is not expanded and causes a compilation error further down
the stack. Based on feedback from #selinux, this works in CIL (should we ever
use it).
Make the relevant policy bit ifdef()'ed based on the distro.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The appstream-metadata interface sets up access to the host's
/var/cache/app-info. When the interface gets connected, both snapd and
snap-update-ns, check the directory. On SELinux systems, that location is
labeled as fwupd_cache_t. Update the policy to allow searching that location.
The denials are:
----
time->Wed Jun 3 14:11:06 2020
type=AVC msg=audit(1591186266.798:588): avc: denied { getattr } for pid=1596 comm="snapd" path="/var/cache/app-info" dev="dm-0" ino=1182576 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=dir permissive=1
----
time->Wed Jun 3 14:11:06 2020
type=AVC msg=audit(1591186266.857:589): avc: denied { getattr } for pid=3530 comm="snap-update-ns" path="/var/lib/snapd/hostfs/var/cache/app-info" dev="dm-0" ino=1182576 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=dir permissive=1
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
When a process forked by snapd (eg. unsquashfs) calls getpw*() it may eventually
go through NSS. Depending on host configuration, it is possible that it will hit
nss-systemd and poke systemd-userdb.service. With current policy this triggers
the following denials:
type=AVC msg=audit(05/22/20 03:37:54.119:665) : avc: denied { read } for
pid=27932 comm=unsquashfs name=userdb dev="tmpfs"
ino=13308 scontext=system_u:system_r:snappy_t:s0
tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0
tclass=dir permissive=1
type=AVC msg=audit(05/22/20 03:37:54.119:666) : avc: denied { write } for
pid=27932 comm=unsquashfs name=io.systemd.DynamicUser
dev="tmpfs" ino=63792 scontext=system_u:system_r:snappy_t:s0
tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0
tclass=sock_file permissive=1
type=AVC msg=audit(05/22/20 03:37:54.120:667) : avc: denied { sendto } for
pid=27932 comm=unsquashfs path=userdb-0f2255de09b5cbb97ed30ae81eda322e
scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:snappy_t:s0
tclass=unix_dgram_socket permissive=1
Update the policy to allow use of nss.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
