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 SNAP_APP_USER_DATA_PATH to be set to /root/apps/.... With either proposal, everything is consistent and usability and security concerns are addressed. Can an architect comment on these proposals or offer an alternative? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1466234 Title: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1466234/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
