* i/b/shared-memory: error on invalid plug attribute
The isPrivate() method assumes that a plug has been sanitised by
BeforePreparePlug and panics if there's no "private" attribute.
There's been a customer report of this happening and even though the
it's unclear how the attribute is missing/wrong, we should handle it
as gracefully as we can instead of panicking.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
* i/b/shared-memory: split else/if
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
* interfaces: deal with missing shared-mem `private` attr correctly
The private attribute in the shared-memory interface may be
not in the `isPrivate()` call. This can even happen if
"SanitizePlugsSlots()" is called (which in turn calls
BeforePreparePlug() which will set `private`).
The code-path in which this happens is an upgrade from snapd
2.54.4 where shared-memory did not have the "private" attribute
yet. Then the ConnectedPlug data is written into the
interface repo without this attribute and on regeneration
of security profiles the connectedPlug is loaded from the
interface repository in the state and not from the
snap.yaml so this attribute is missing.
The correct behavior is that `private` is set to false which
is the default when it's not set in snap.yaml as it can only
end up in this state if it was unset.
---------
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
* i/apparmor: support for home.d tunables from /etc/
* tests: update snapd-homedirs-vendored to run on all ubuntu versions
* i/apparmor: add additional unit test
Only enable the spread test for ubuntu 20 and newer as any distro before don't support the neccessary features
---------
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
* sandbox/apparmor: don't let vendored apparmor conflict with system
Don't enable the vendored apparmor if the system installed apparmor will try and
load policy that would be generated by the vendored apparmor and hence may
conflict with that by using newer features not supported by the system installed
apparmor (LP: 2024637)
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* apparmor: add unit testing for SystemAppArmorLoadsSnapPolicy()
* tests: add test that checks regression in lp-2024637
* apparmor: only log non ENOENT errors in systemAppArmorLoadsSnapPolicy
* tests: fix snapd-snap test on 14.04-18.04
This commit will skip apparmor vendor testing if /lib/apparmor/functions
still references /var/lib/snapd/apparmor/.
See LP:2024637
* tests: fix typo in snapd-snap test
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* i/apparmor: allow read of /lib/apparmor/functions in snap-update-ns
Snapd at startup will inspect this file now to ensure that the
vendored apparmor can be used. So the snap-update-ns profile
also needs to get updated as this happens during an early init().
---------
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
* many: move SnapConfineAppArmorDir from dirs to sandbox/apparmor
Then when using the internal vendored AppArmor, use a different location for
SnapConfineAppArmorDir so that we don't interfere with the system installed
AppArmor.
In Ubuntu, the snapd deb includes an AppArmor profile for
/usr/lib/snapd/snap-confine that includes any profile snippets from the
hard-coded directory of /var/lib/snapd/apparmor/snap-confine. When we use the
snapd snap with the vendored AppArmor, this may contain newer features and so
would create snippets under /var/lib/snapd/apparmor/snap-confine that then may
not be supported by the system installed AppArmor. When the system installed
apparmor.service would run on boot, it would try and load the snap-confine
AppArmor profile shipped in the snapd deb, which would then try and include
these snippets generated by the newer vendored AppArmor and could fail to load
them as they would use new features not supported by the system AppArmor.
So instead, when using the vendored AppArmor, have snapd use a different
directory for the snap-confine profile snippets and then have the
snapd-generated AppArmor profiles for snap-confine reference this location
instead. This should allow to support both use-cases simultaneously.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
* apparmor: add unit test that ensures that snap-confine include snippet is rewriten
* sandbox/apparmor: add unit test around setupConfCacheDirs()
* tests: add check check in snapd-snap for /v/l/snapd/apparmor/snap-confine.internal path usage
* tests: fix spread test to look at the right profiles
* i/apparmor: allow read of /usr/lib/snapd/info in snap-update-ns profile
---------
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Co-authored-by: Michael Vogt <mvo@ubuntu.com>
Module loading generates event for devpath /module/<nameofmodule>.
Some modules and devices have the same KERNEL name. For example
rfkill. We need to ignore module insertions. Otherwise we get
error message when trying to run snap-device-helper.
* account_control: allow local user account management
This MR adds support for adding, removing and modifying the users.
It is required for Core Desktop.
* Remove peer entries
* Add peer=(label=unconfined)
It works the same.
* Add extra peer=(label=unconfined)
It looks like some changes in apparmor 3.1.4 cause issues with
the existing network-control rules. It appears the rules are
stricter now.
Thie commit updates the rules to match the new behavior, see
also https://bugs.launchpad.net/apparmor/+bug/2023025
Currently, any application that connects to the audio-playback or
the pulseaudio insterfaces, have write permissions to the pulse/
folder. This means that a snapped malicious application would be
able to delete the socket and put its own, being able to read the
audio of any other snapped application.
This patch removes those permissions.
* Remove unneeded rules
The "owner /run/pulse/native/ rwk" rule is already managed by a
similar previous one. Also, there is no need to allow to link the
pulse folder.
Tested both in Firefox and Telegram, and everything still works
fine.
We have a bugreport where even with an active gpio-control interface
the gpio devices cannot be accessed. The path in question is:
```
/sys/devices/platform/INT33FC:02/gpio/gpio346/direction
```
Hower we only allow:
```
/sys/class/gpio/gpio[0-9]*/{active_low,direction,value,edge} rw,
```
in our gpio-control policy.
To fix that issue this commit allows gpio prefixes that start
with /sys/devices/platform instead.
* interfaces: add comment about /sys/devices/platform/*/gpio/gpio[0-9]*/ in gpio-control
This allows bind for org.bluez.obex.* which is necessary for the
agents that are created as well as the send for the
org.bluez.AgentManager1 interface.
This change alphabetizes the supported kernel mount options, as well as
moves `zfs` after `xfs` in the list of default filesystems.
Filesystem-specific mount options are not alphabetized, and are instead
left in the order they are defined in their documentation or source
code in order to ease visual verification of their correctness.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: fix custom-device default udev kernel rules
The KERNEL value in udev rules must be the basename of the device path.
For devices for which there is not a matching kernel value specified in
the custom-device `udev-tagging` section, a default udev kernel rule is
generated. Previously, https://github.com/snapcore/snapd/pull/12734
(and prior) generated these default rules by using the complete device
path relative to `/dev/`. However, for device paths which are in
subdirectories of `/dev/`, this means that the kernel values were not
basenames, which violates the udev spec.
This commit changes this behavior to instead generate udev kernel rules
using the basename of each specified device.
Since ambiguity would arise if multiple devices had the same basename,
this change introduces a check to ensure that all the specified devices
have unique basenames.
Additionally, this commit introduces a check to ensure that all
specified kernel values in the `udev-tagging` section are basenames.
It is still the case that each specified kernel value must match one of
the specified devices.
There are currently problems with `vet` where it is claimed that several
of the `[]string` variables in `validateUDevDevicesUniqueBasenames()`
are unused. These variables are used in a several ways, so further
investigation is required as to why this is the case.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* prompting/storage: fixed missing variable assignment from append()
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* prompting/storage: fixed custom device duplicate basename error message
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: fixed custom-device unit tests introduced by commas in filepaths PR
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: adjusted custom-device comment for kernel not matching any devices
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: fixed unit test for when custom-device kernel does not match any device
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
* interfaces/builtin: moved custom-device unique basename check
This change moves the check for whether all specified devices have
unique basenames out of `validateUDevTaggingRule()` (which is called
once for each udev rule) into `BeforePrepareSlot()`, immediately after
the list of device paths is assembled and each path validated. Thus, it
is only called once, before any rule validation begins.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
---------
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
