~/snap directory should be o0700

Bug #1910298 reported by James Troup
274
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snapcraft
Triaged
High
Sergio Schvezov
snapd
Fix Released
Medium
Miguel Pires

Bug Description

IMO, .cache, .config (and probably .local) directories created under ~/snap/ should be o0700 as they are in ~/

ATM, that doesn't appear to be the case, e.g.

  https://pastebin.canonical.com/p/XhbnKcCFxk/
  https://pastebin.canonical.com/p/4DYYqVZkBQ/

CVE References

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I think this is because https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/init#L19. Note that ensure_dir_exists is used by including scripts to create the cache dir, but the function doesn't set the permissions.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ken, since this is in snapcraft-desktop-helpers, I've subscribed you to the bug. Note that fixing this would require snaps to be rebuilt ala https://forum.snapcraft.io/t/ann-snapcraft-4-4-4-library-injection-vulnerability-on-built-snaps/21465. Please work with the security team on coordinating a fix in snapcraft-desktop-helpers.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

In addition to snapcraft-desktop-helpers, it appears that at least some snaps that don't use the helpers are getting this wrong. Ian Johnson mentioned that the 'peruse' snap suffers from this. IMHO, snapd on principle shouldn't be in the business of second guessing publisher intent wrt creating or fixing .cache directories in the snap data directories and that this is technically a 'snap problem'. While that may be true, we should be open to discussing potential remediations.

It is clear that if XDG_CACHE_HOME is set and a (eg, staged) library is not setting the permissions to 0700, then that library would clearly need a fix.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I'm reminded that the desktop-helpers are part of modern snapcraft. Thinking through that, I think that snapcraft may be in a position to fix the cache directory even for snaps that don't use the helper on the justification that if you're using snapcraft, it may be opinionated about things (that requires more discussion of course).

Revision history for this message
James Troup (elmo) wrote :

Uh, can I also add .config to the mix?

  https://pastebin.canonical.com/p/4DYYqVZkBQ/

summary: - .cache directories in ~/snap/ should be o0700
+ .cache and .config directories in ~/snap/ should be o0700
Revision history for this message
Ken VanDine (ken-vandine) wrote : Re: .cache and .config directories in ~/snap/ should be o0700

the desktop helpers create .config with 0700 but that got lost in the transition to the snapcraft extension.

From the helpers:
# Set config folder to local path
export XDG_CONFIG_HOME=$SNAP_USER_DATA/.config
ensure_dir_exists $XDG_CONFIG_HOME -m 700

This isn't in snapcraft, it does an ensure_dir_exists $XDG_CONFIG_HOME/fontconfig which create $SNAP_USER_DATA via the mkdir -p. The explicit creating of that dir was probably seen as redundant, but we do need that.

Revision history for this message
Ken VanDine (ken-vandine) wrote :
James Troup (elmo)
description: updated
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

A few questions:

- is this going to have a CVE?
- is this going to require semi-private code and snap branches?
- do we want to check perms in the extension and change them (even if it impacts startup performance) or only do the right thing for new setups?

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

Last question, should the ~/snap/$SNAP_NAME/$SNAP_REVISION and ~/snap/$SNAP_NAME/common directories be set o0700 for snaps that do not use the extension/helpers?

Revision history for this message
Ian Johnson (anonymouse67) wrote :

Hi folks, we just discussed this on the snapd team, and we think that:

1. snapd should make ~/snap 0700 - this will protect against all such ~/snap/<snap-name>/current/.{cache,config,local} etc directories leaking information
2. There is an open question about when snapd should make this change

If it's agreed that instead of snapd making ~/snap 0700, snapd should just make all ~/snap/<snap-name>/{current,common}/.something directories 0700, then there's a question of when this change should be made, because I think we need to assume that vulnerable snaps will continue to be available in the store for a long time, and so we need to make sure that folks who install those snaps newly after disclosure do not suffer from the information leak.

Also, I strongly think this should get a CVE, who from the security team is coordinating this?

Changed in snapd:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Ian Johnson (anonymouse67) wrote :

An orthogonal fact to this is the proposal from Alex Murray (and others) on https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734 (and https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2020-November/018842.html), which proposes that user's home directories are 0700 by default for hirsute, which I think aligns well with the intent of making the ~/snap directory 0700.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

I've merged the fix for snapcraft-desktop-helpers

Revision history for this message
Ian Johnson (anonymouse67) wrote :

After discussion with the security team, we decided that a CVE is relevant for this bug, but that it doesn't need to be private, so I've set it as public.

I also discussed the idea of having snapd set the permissions for user's ~/snap directories to 0700, and it was generally agreed that was a good idea, so long as it is done with adequate frequency; the fix should probably be done by snapd or snapd's userd on every startup to account for the fact that some users might not use snaps frequently (and thus a solution that I proposed by having `snap run` do the fix) and they should still be protected.

information type: Private Security → Public Security
Changed in snapd:
assignee: nobody → Ian Johnson (anonymouse67)
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Please use CVE-2021-3155 for this issue. Thanks.

Revision history for this message
Ian Johnson (anonymouse67) wrote :

We discussed this again and we will implement a fix for this in 2 places:

1. when a snap is executed with snap run
2. in the snapd userd autostart user session agent which autostarts upon login into a desktop session with snaps installed that auto-start (such as snap-store)

This should cover a majority of the cases and eventually should percolate to all relevant users over time.

summary: - .cache and .config directories in ~/snap/ should be o0700
+ ~/snap directory should be o0700
Changed in snapd:
status: Confirmed → In Progress
Revision history for this message
Ian Johnson (anonymouse67) wrote :

PR for snapd userd autostart (but not the user session agent that is subtly different in relevant ways actually, it doesn't actually always run, only when a user has installed a snap which uses user session scoped daemons, which is still experimental) is here: https://github.com/snapcore/snapd/pull/9897

A PR for snap run will be later on.

Changed in snapcraft:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Sergio Schvezov (sergiusens)
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Has there been any progress in fixing this CVE?

Revision history for this message
Ian Johnson (anonymouse67) wrote :

My snapd PR is just waiting on a review from the security team, there will be another follow-up PR to snapd afterwards however

Changed in snapd:
assignee: Ian Johnson (anonymouse67) → Miguel Pires (miguelpires1)
importance: High → Medium
Revision history for this message
Miguel Pires (miguelpires1) wrote :
Changed in snapd:
status: In Progress → Fix Committed
Changed in snapd:
status: Fix Committed → Fix Released
milestone: none → 2.54
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers