Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root

[Stéphane Graber]

So apparently in current snappy, root has less rights than random joe.

That should be fixed.

21:31 < stgraber> [94170.804198] audit: type=1400 audit(1434576560.135:55): apparmor="DENIED" operation="mkdir" profile="lxd_lxc_0.11-0"
                  name="/root/apps/lxd/0.11-0/.config/" pid=6085 comm="lxc" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
21:32 < jdstrand> stgraber: oh, that is because we are using @{HOMEDIRS}/*/ instead of @{HOME}. @{HOMEDIRS}/*/ does not include /root.

[Jamie Strandboge (jdstrand)]

This is an easy fix policy-wise. Ie, change all occurrences of '@{HOMEDIRS}/*/' to '@{HOME}/' in the policy. However, we actively decided that '/root' would not be included in the default policy, and I'd like to understand why. Is this for the FHS? How does this affect rollbacks? Is /root handled in the same manner as /home?

[Ted Gould (ted)]

It kinda seems to me like SNAP_APP_USER_DATA_PATH shouldn't be set for things running as root. It seems that any service should be using SNAP_APP_DATA_PATH. Is there a specific reason to try to write into a user's directory instead of the per-service writable directory?

[Jamie Strandboge (jdstrand)]

This bug affects usability. If you install a snap and run one of its binaries with 'sudo foo.bar' then /home/ubuntu/apps gets created as root and subsequent commands run as non-root will fail to create their user data directories. I like ted's reasoning but ultimately I don't think we shouldn't second guess the application. There is precedent for this all over the place with (OTOH) ssh, gpg and openssl all creating their dot files/directories under /root when they are run as root.

If the application is intentionally using SNAP_APP_USER_DATA_PATH and is running as root, we should set SNAP_APP_USER_DATA_PATH to /root/apps/<name>/<version>.... This means the launcher needs to change and the apparmor policy.

Adding tasks for those (which we can remove later if others think something else should be done).

[Jamie Strandboge (jdstrand)]

Actually, the bug description shows that lxd *did* get a directory under /root, but latest stable does not do that.

$ sudo rm -rf /home/ubuntu/apps
$ sudo hello-world.env
$ sudo ls -ld /home/ubuntu/apps
drwxr-xr-x 3 root root 4096 Oct 1 08:18 /home/ubuntu/apps

So something may have changed with the launcher since this bug was originally filed (or lxd was trying to work around it).

[John Lenton (chipaca)]

I think the least surprising thing to do would be to use /root/apps/<name>/<version> for SNAP_APP_USER_DATA_PATH when running an app with sudo.

[Jamie Strandboge (jdstrand)]

This came up in the context of another conversation, but then we discussed it. The security team reexamined the current behavior and don't like that SNAP_APP_USER_DATA_PATH is being set to the real uid when the effective uid is root. Apart from the usability concern expressed in this bug, from a security standpoint this allows the user to modify files that are used by root and also allows a malicious snap to chmod files in the user's home directory.

Since it seems a few things have changed since this bug was filed, I'll restate the current situation:
* /apps/bin/... wrappers are setting export SNAP_APP_USER_DATA_PATH="$HOME/apps/..."
* /apps/bin/... wrappers mkdir SNAP_APP_USER_DATA_PATH under the effective user (so, if run under sudo, then root owned dirs under /home/ubuntu)
* systemd services use SNAP_APP_USER_DATA_PATH to '%h/apps/...'. According to http://www.freedesktop.org/software/systemd/man/systemd.unit.html, "%h - User home directory - This is the home directory of the user running the service manager instance. In case of the system manager this resolves to "/root".
* /root is currently included in /etc/system-image/writable-paths and is therefore writable
* the apparmor policy does not allow writes to /root/apps/...

Observations:
1. /apps/bin/... wrappers correctly set SNAP_APP_USER_DATA_PATH to /home/$user/apps/... and mkdir this dir when run as non-root
2. /apps/bin/... wrappers mkdir SNAP_APP_USER_DATA_PATH as root in the user's home directory (usability bug from comment #3)
3. /apps/bin/... wrappers when run under sudo set SNAP_APP_USER_DATA_PATH to something different than the systemd unit file
4. the apparmor policy currently doesn't work with the systemd unit (this bug)

In comment #1 I asked for more information on why we didn't want to use /root/apps/... when run as root, but didn't get a response. It's possible at the time the security policy was written I was instructed to not allow it since /root wasn't writable, but it is now. I also addressed Ted's concern in comment #

In an effort to prod this bug along, I suggest that we clean up all of this with the following:

Proposal #1:
1. continue to have /apps/bin/... wrappers correctly set SNAP_APP_USER_DATA_PATH to /home/$user/apps/... and mkdir this dir when run as non-root
2. adjust /apps/bin/... wrappers to set SNAP_APP_USER_DATA_PATH to /root/apps/... and mkdir this dir when run as root (eg, under sudo)
3. adjust the apparmor policy accordingly
4. adjust snappy to handle /root in the same manner as /home/$user wrt rollbacks and upgrades.

I suspect rollbacks and upgrades to be the point of contention with this proposal.

Proposal #2:
1. continue to have /apps/bin/... wrappers correctly set SNAP_APP_USER_DATA_PATH to /home/$user/apps/... and mkdir this dir when run as non-root
2. adjust /apps/bin/... wrappers to set SNAP_APP_USER_DATA_PATH to SNAP_APP_DATA_PATH (ie, /var/lib/apps/...) and skip any mkdirs of SNAP_APP_USER_DATA_PATH when run as root (eg, under sudo)
3. adjust the systemd unit to set SNAP_APP_USER_DATA_PATH to SNAP_APP_DATA_PATH (ie, /var/lib/apps/...)

This introduces the least amount of change to snappy but might be confusing to developers expecting S...

[Gustavo Niemeyer (niemeyer)]

There seems to be two related but independent problems here.

The first one is the original problem reported in the description above: the snap user directory is inaccessible to the snap itself. This should indeed be fixed, and there's apparently no reason for us to move this data out of $HOME that is set for uid=0 (proposal #2), as that's what we have for every other user.

The second problem is that sudo works as it usually does, with some of the environment from the calling user. The answer to this one feels slightly less obvious, but I'm tempted to suggest following the usual route of setting the data path to the effective user id, to avoid this sort of ownership problem. Unfortunately, this also implies that applications will no longer run with the context of the calling user under sudo, and I'm not sure of the implications that this will unfold at this point, but perhaps it's okay to try and see.

[Jamie Strandboge (jdstrand)]

Thanks Gustavo. We discussed this a little bit more on irc and agree that proposal #1 is the way to go for now. If we need to refine that in the future we can.

[Jamie Strandboge (jdstrand)]

ubuntu-core-security 16.04.7 has the apparmor change for /root/apps and is in xenial-proposed.

[Jamie Strandboge (jdstrand)]

Marking the ubuntu-core-launcher task as invalid since it doesn't require any changes with proposal #1.

[Jamie Strandboge (jdstrand)]

Adding ubuntu-snappy task since it needs to be modified for proposal #1. Triaging to the level of the Snappy project task.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-core-security - 16.04.7

---------------
ubuntu-core-security (16.04.7) xenial; urgency=medium

  * ubuntu/default: allow owner match on @{HOME} instead of @{HOMEDIRS}/*/
    to allow root access to SNAP_APP_USER_DATA_PATH when it is set to
    '/root/apps/...' (LP: #1466234)

 -- Jamie Strandboge <email address hidden> Tue, 01 Dec 2015 13:43:20 -0600

[Kyle Fazzari (kyrofa)]

Any update here?

[Kyle Fazzari (kyrofa)]

Bugfix here: https://github.com/ubuntu-core/snappy/pull/264

[Michael Vogt (mvo)]

root@localhost:/home/ubuntu# hello-world.sh
Launching a shell inside the default app confinement. Navigate to your
app-specific directories with:

This works now in snappy 16:

bash-4.3# cd $SNAP_USER_DATA
bash-4.3# pwd
/root/snap/hello-world/25
bash-4.3# touch lala
bash-4.3# ls
lala