Ubuntu
snapd package

snapd fails to create a device cgroup for strict mode snaps that have no matching udev tagged devices

Bug #1988261 reported by Alex Murray
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
New
Undecided
Unassigned

Bug Description

Currently snap-confine within snapd will only create a device cgroup and hence implement this access control mechanism for snaps which plug/slot an interface that adds udev rules for a set of devices. As such, in the case that say AppArmor is not available or can be bypassed, there is no access control implemented for device files.

Instead, snap-confine should always create a device cgroup for all strict mode snaps.

It seems this change occurred in https://github.com/snapcore/snapd/commit/42a3ee56110046e01bb169ba846ce633db0daf57 but the comment in this commit suggests that even before then this may have been the case. However, at least back when snapd supported only cgroupv1 this was not the case as can be seen in https://github.com/snapcore/snapd/blob/aab394fc65b8fdc1fdb68e7275dca5e3b6aec856/cmd/snap-confine/udev-support.c#L389 where it looks like this was always unconditionally created.

Am tagging this as security since it relates to sandboxing but as this is an additional hardening measure I do not think it qualifies as a security vulnerability in-and-of itself.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Hello Alex.

I know about this feature but when we last tried to change it, it was a breaking regression for a number of snaps that rely on this (mis)feature, including high-profile snaps like greengrass.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Note: the device cgroup was indeed always created, but in absence of tagging it was permissive.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

In retrospective I think we should have made the breaking change back then and grant extra permissive interface to the select snaps that needed it. In the Montreal sprint many many years ago we recognized that snaps do not correctly transition from tagged to untagged and that this is potentially very risky.

Revision history for this message
Alex Murray (alexmurray) wrote :

Zyga can you expand a bit more on your comment re "snaps do not correctly transition from tagged to untagged" - do you mean that if a snap has a bunch of interfaces connected which have udev rules, then these get disconnected, that it then is still allowed access to those devices via the device cgroup?

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

My memory is definitely rusty on this but please review snap-confine logic with regards to how cgroup v1 device behaves: in absence of tagging it is a permissive model, with tags, that are happening dynamically at runtime, you get non-permissive mode with specific exceptions that are allowed.

There is nothing in the code to react to udev events to update existing sandbox for running processes. This is equally true of dynamic connect/disconnect of snap interfaces. Apparmor is altered in-place but device group does not.

This can create the situation where apparmor allows something broad, relying on udev tagging that didn't happen.

In my past approach I was trying to get so that new program would run some new logic in response to udev tagging events, so that the sandbox would behave consistently.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.