~/snap directory should be o0700

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.

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.

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.

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).

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

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

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.

PR submitted for desktop helpers https://github.com/ubuntu/snapcraft-desktop-helpers/pull/218

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?

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?

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?

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.

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

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.

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

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.

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.

Has there been any progress in fixing this CVE?

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

Follow-up to Ian's PR: https://github.com/snapcore/snapd/pull/10992