microstack requires read access to @{PROC}/*/{,task/*/}sched and
@{PROC}/*/{,task/*/}schedstat to allow virsh to read cpu statistics
of the instances.
Without this rule, openstack-hypervisor.virsh domstat list does not
print cpu statistics, vcpu.<id>.time, vcpu.<id>.stat.
Apparmor deny rule in dmesg:
[98847.604617] audit: type=1400 audit(1693470840.357:1499): \
apparmor="DENIED" operation="open" profile="snap.openstack-hypervisor.libvirtd" \
name="/proc/2014588/task/2014595/sched" pid=3668724 comm="rpc-libvirtd" \
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
This rule is also required by ceilometer service running on the
openstack-hypervisor snap which queries libvirt for the cpu/memory/disk
statistics of the instances running on hypervisor.
incorporate into it and update the patterns described in basedeclaration.go
have a few relevant doc comments point to it
* tweaks
* interfaces: incorporate suggestions from @degville with some tweaks
thanks
* interfaces: incorporate fixes from @MiguelPires
thanks
This is a first go at an interface to allow a snap to register as a Polkit agent. The primary use case is for the Ubuntu Core Desktop system we're building. The implicit slot is not available on classic systems, since there is no reasonable way to implement it given the variability in the PAM and NSS configurations found on those systems.
Here's a brief description of how a Polkit agent operates:
The agent registers with polkitd by calling the RegisterAgent D-Bus method. In general, it will register as an agent for all processes that belong to a particular logind session.
When a system daemon makes a CheckAuthorization call to polkitd for a subject that is covered by the agent, polkitd will make a BeginAuthentication call to the agent. This includes the requested action ID, a message to show the user, and a cookie string to identify the authentication request.
The agent runs the setuid polkit-agent-helper-1 executable as a sub-process. The helper begins the PAM authentication process, and delegates any prompts to the agent via messages on stdin/stdout.
On completion of the authentication process (either success or failure), the helper makes an AuthenticationAgentResponse2 method call to polkitd, using the cookie to identify the request. Polkitd trusts the response because the D-Bus connection credentials show that the helper is running as root.
Polkitd responds to the system daemon with this result, allowing it to decide how to respond to its client.
This poses a number of difficulties for a snap based system:
The snap needs to be able to execute a setuid binary.
The setuid binary is going to inherit some security config from its parent process, including:
mount name space: it will be running in the snap's sandbox, so the sandbox will need to provide all the PAM modules referenced by the system's configuration, and have access to all data files and services those modules use.
seccomp filters: the parent's seccomp filter will need to allow all access the setuid helper requires. One obvious case that has come up is access to the kernel audit subsystem.
The need to support the host system's PAM config mostly rules out getting this to work on Classic systems. On Core systems though, things will generally work if the snap uses the same base as the boot file system (or something sufficiently similar).
The interface makes use of AppArmor's ability to switch profiles on exec(). We switch to a sub-profile tailored to what polkit-agent-helper-1 needs. Namely:
Include nameservice and authentication abstractions to enable use of PAM. Also grant access to extrausers shadow files, which aren't currently included in authentication.
Allow audit_write and sys_nice capabilities, which are used by the installed PAM modules
Allow SIGTERM signals from the calling snap: this is sent when the user cancels authentication. The corresponding rule allowing the agent to send the signal is covered by the default snap AppArmor template.
Allow communication with polkitd over the D-Bus system bus to make the AuthenticationAgentResponse2 method call.
The interface is locked down with allow-installation: false on the plug side, since it allows running a privileged process in a mount namespace under the control of the snap. Through the use of layouts, it's possible that the snap could replace shared libraries loaded by the helper. Even though the helper is locked down through an AppArmor sub-profile, it seems reasonable to vet snaps that request this access.
I don't have a spread test for this, as we don't have any ubuntu-core-* systems with polkit integrated, and I'm not all together certain how I'd structure a test for this. We have been manually testing the interface on Core Desktop builds though.
* interfaces: add a polkit-agent interface
* interfaces: use a subprofile to run polkit-agent-helper-1 in polkit-agent interface
* interfaces: only look for polkit-agent-helper-1 in /usr/libexec
Prior to Ubuntu 22.04, the polkit executables were installed in
/usr/lib/policykit-1. As there is practically zero chance of polkit
being integrated into these older Ubuntu Core versions, there's no
benefit checking the old path.
* account_control: add locale1 support
This PR adds support for the org.freedesktop.locale1 DBus
interface. It is required for Ubuntu Core Desktop and for
the installer.
Fix git checkout -b UDENG-1110-add-locale-1-dbus-interface-support-in-snapd
* Move locale1 dbus to locale_control
It makes more sense to have the locale1 access in the
locale_control interface.
* Changes requested by James
* Remove unneeded peer command
let connect/auto-connect only to an upower-observe implicit slot by default,
this will require changes to review-tools to detect that for an app slot
dedicated rules in snap-declaration are needed
these can be useful in the base-declaration in situations where
a slot can be app-provided or implicit both on classic and core
now we have at least one use case like this for upower-observe
as core/system snaps so far provide only slots there is no use
case for adding plug-side plug-snap-type connection constraints
Replace ioutil.WriteFile with os.WriteFile since the former has been
deprecated since go1.16 and simply calls the latter.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
On Core Desktop, the upower-observe interface is available as an
implicit slot. We want to make the same kind of implicit vs. app snap
distinction in AppArmor rules as we would on classic systems. Allowing
the implicitSystem*Slot() helpers to return true on Core systems
achieves this.
* Mount system fonts via app desktop slot
* interfaces: update desktop tests to match changes to interface
* interfaces: note that desktop interface allows app slot implementations
* tests: add desktop slot to test-snapd-policy-app-provider-core
* interfaces: deny connection of desktop interface by default on Ubuntu Core.
* tests: add a spread test for providing a desktop slot on Ubuntu Core
* interfaces: add support for xdg-desktop-portal to app-provided desktop slot
In this setup, we expect xdg-desktop-portal and xdg-document-portal to
be running outside of confinement (as snap userd does), with the user
interface backend services running in the context of the slot snap.
* interfaces: add a comment about the assumption that a snap providing a
desktop slot uses the boot base snap as its base.
* Fix documents portal not being launched
It uses a different bus name from the desktop portal.
* interfaces: fix up permanent slot rules for desktop interface
* interfaces: update desktop slot declaration to only allow app snaps to provide the slot under the minimal install check
* interfaces: add access to files necessary for xdg-user-dirs to the
desktop slot
* interfaces: add file access covering what the ubuntu-desktop-session:shell-config-files system-files plug granted
* interfaces: add a comment noting the unusual base declaration for desktop
* interfaces: make desktopPermanentSlotAppArmor a constant
---------
Co-authored-by: Marcus Tomlinson <marcus.tomlinson@canonical.com>
Co-authored-by: Robert Ancell <robert.ancell@canonical.com>
Co-authored-by: Ken VanDine <ken.vandine@canonical.com>
* interfaces/builtin: fix custom-device udev KERNEL values
Previously, the handling of udev tagging rules was modified to allow
device paths in subdirectories of `/dev/`. As part of this work,
checks were put in place to ensure that all KERNEL values, including
default rules, must be basenames of a device path.
That work can be found in two previous commits:
- b1df21de47
- 12ca6af3a0
The former allows either full paths (stripped of leading `/dev/`) or
basenames, while the latter switches this requirement so that all values
must be basenames. The commit message of the latter indicates that
KERNEL values which are not basenames violate the udev spec -- this is
incorrect.
For some devices, the udev KERNEL value must be the full path of the
device, stripped of leading `/dev/`, while for other devices, the udev
KERNEL value must be the basename of the device path. If an explicit
udev tagging rule is not given, it is unclear which of these is the
case.
This commit changes udev tagging handling to emit two rules for each
device path in a subdirectory of `/dev/` which is not given as the
kernel value of an explicit udev rule in the "udev-tagging" section:
one using the full device path following `/dev/`, and one using the
basename of the device path.
If there are device paths of the form /dev/bar and /dev/foo/bar, then
default rules will be generated for both KERNEL=="bar" and
KERNEL=="foo/bar". If there are explicit rules for either, the default
rule for the other (if it has no explicit rule) will still be emitted.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: custom-device removed unused helpers
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: custom-device refactored default rule generation
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: custom-device refactored udev-tagging rule validation
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: custom-device improve unit tests for devices with shared basename
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: custom-device add log message when basename rule applies to non-basename device
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
