Snap application prevents daemon refresh

Bug #1978005 reported by Stéphane Graber
278
This bug affects 4 people
Affects Status Importance Assigned to Milestone
snapd
Fix Released
Critical
Miguel Pires

Bug Description

NOTE: Filing this as a security issue as the new snapd behavior allows anyone on the system to hold security updates of a very security sensitive daemon.

Recently we've noticed that having something like "lxc exec" running on the system will prevent refreshes of the "lxd" snap. I understand why this would be a valuable behavior for something like firefox, but this is causing some pretty serious issues for LXD leading to this being marked as a security issue (a public one though).

LXD itself understands refreshes, on refresh, our daemon is signaled and it will cancel the bulk of its connections and background tasks, then wait an additonal 5min for any long running connections like "lxc exec" to complete, then kill off the rest and restart.

This behavior both allows for security updates to be applied in a timely manner as well as for clusters to upgrade within a rasonable timeframe. LXD cluster updates must be applied to all servers prior to the cluster being functional again, so we can't have one server holding things for a prolonged period of time.

Prior to the change of behavior in snapd, everything was fine for us. A normal refresh could be delayed for up to 5min by LXD and similarly, a cluster would normally be fully refreshed within 5min.

With the new behavior, a single "lxc exec" or "lxc monitor" running on the system will prevent any refresh of LXD. We've now seen cluster being stuck for hours/days because of this.

And now for the security issue. A user who's not even part of the privileged "lxd" group, can cause a "lxc" command to run indefinitely, which then prevents the system from applying security updates to the LXD daemon. This could be used on e.g. cloud instances to immediately connect and prevent snap refreshes, then being able to attack a much older, potentially vulnerable LXD at one's convenience.

To be clear, the new behavior in general seems reasonable but there needs to be a clear way to opt-out specific snaps or specific applications within a snap. Looking at the snapd code and YAML definition, I'm not seeing a way to do so today.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Setting as "public security" given the issue was already discussed publicly on IRC.

information type: Private Security → Public Security
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Here's a quick idea on how this can be addressed https://github.com/snapcore/snapd/pull/11855

Changed in snapd:
importance: Undecided → High
status: New → Triaged
Michael Vogt (mvo)
Changed in snapd:
importance: High → Critical
Revision history for this message
Michael Vogt (mvo) wrote :

I'm inclined to switch the default of refresh-app-awarness again and did this in https://github.com/snapcore/snapd/pull/11912 - I think we want to fix this properly but the team does not have the resources right now to fully tackle it.

Revision history for this message
Adam Collard (adam-collard) wrote :

Workaround is to `snap set system experimental.refresh-app-awareness=false` to flip the bit on the feature flag - hopefully https://github.com/snapcore/snapd/pull/11912 will do that in the next release

Revision history for this message
Miguel Pires (miguelpires1) wrote :

This issue has been addressed by this PR: https://github.com/snapcore/snapd/pull/11855

Changed in snapd:
assignee: nobody → Miguel Pires (miguelpires1)
status: Triaged → Fix Committed
Changed in snapd:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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