allow browsers to use user namespaces in its sandbox

[Chad Miller]

AppArmor is blocking chromium's use of user namespaces:

apparmor="ALLOWED" operation="open" profile="snap.chromium.chromium" name="/proc/NNNNN/setgroups" pid=NNNNN comm="chromium-browse" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
apparmor="ALLOWED" operation="open" profile="snap.chromium.chromium" name="/proc/NNNNN/uid_map" pid=NNNNN comm="chromium-browse" requested_mask="w" denied_mask="w" fsuid=1000

As a workaround, chromium can disable its sandbox when running under snapd. Longer term snapd should leverage the apparmor stacking work to allow snaps to setup user namespaces via interfaces.

= Original text =
As I understand it, we plan to punch holes in AA and seccomp specifically for a new chromium profile. From devmode, I extracted the apparmor denials for chromium browser.

[Chad Miller (cmiller)]

I don't know how to get seccomp denials. Without --devmode, I get "Bad system call", a killed process, and nothing in syslog that looks promising.

$ snappy-debug.security scanlog
WARN: Could not set kernel rate limiting

= AppArmor =
Time: May 27 18:26:29
Log: apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/cmiller/.Private/" pid=19129 comm="ubuntu-core-lau" requested_mask="rw" denied_mask="rw" fsuid=1000 ouid=1000
File: /home/.ecryptfs/cmiller/.Private/ (write)
Suggestion:
* adjust program to write to $SNAP_DATA or $SNAP_USER_DATA

= AppArmor =
Time: May 27 18:26:29
Log: apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/" pid=19129 comm="ubuntu-core-lau" requested_mask="rw" denied_mask="rw" fsuid=1000 ouid=1000
File: /home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/ (write)
Suggestion:
* adjust program to write to $SNAP_DATA or $SNAP_USER_DATA

= AppArmor =
Time: May 27 18:26:29
Log: apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVmlGoq0dj7d2FKctk3XIkSU--/" pid=19129 comm="ubuntu-core-lau" requested_mask="rw" denied_mask="rw" fsuid=1000 ouid=1000
File: /home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVmlGoq0dj7d2FKctk3XIkSU--/ (write)
Suggestion:
* adjust program to write to $SNAP_DATA or $SNAP_USER_DATA

= AppArmor =
Time: May 27 18:26:29
Log: apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVmlGoq0dj7d2FKctk3XIkSU--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVU1RPVUAnysWJtdM9.Q7n0E--/" pid=19129 comm="ubuntu-core-lau" requested_mask="rw" denied_mask="rw" fsuid=1000 ouid=1000
File: /home/.ecryptfs/cmiller/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVm2NAu0yQBQyD7yyIFBnaJE--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVmlGoq0dj7d2FKctk3XIkSU--/ECRYPTFS_FNEK_ENCRYPTED.FWb4VZJUL514cESvVcp5DUiJnlmnLbK3jZjVU1RPVUAnysWJtdM9.Q7n0E--/ (write)
Suggestion:
* adjust program to write to $SNAP_DATA or $SNAP_USER_DATA

[Jamie Strandboge (jdstrand)]

For seccomp snappy-debug.security scanlog will help you, but you can also 'grep audit /var/log/syslog' to see the syscalls and then run them through scmp_sys_resolver on the target machine. However, the seccomp call in question for chromium is known and is bug #1577520 (in progress).

The ~/.Private is bug #1574556 and is fixed in 16.10 and in progress on 16.04.

/dev/.org.chromium.Chromium.NNNNNN is bug #1577514 and a plan is decided and the snappy team will implement. Alternatively, you can also adjust chromium to use /dev/snap.$SNAP.NNNNNN instead and it would work today.

You should adjust the snap to not use /etc/chromium-browser/policies/managed/ and /etc/chromium-browser/policies/recommended/ since they won't exist in the snap's filesystem anyway.

Read access for /proc/NNNNN/oom_score_adj is fixed in trunk but write access won't be allowed at this time because it allows a snap to influence the oom killer for other snaps (but this is a noisy denial, not fatal and we'll work through silencing these sorts of things in future work).

/proc/NNNNN/setgroups and /proc/NNNNN/uid_map seem to be because of chromium's use of user namespaces. Please disable the sandbox at this time since snappy is handling confinement. Once the phase 1 apparmor stacking changes all land in 16.04 (most have, some remain) we can revisit chromium's use of user namespaces and see what interface changes are needed.

/usr/share/applications/ and /var/lib/snapd/desktop/applications/ appear to be for xdg-mime, however snapd is moving to its own implementation of xdg-open that snaps would use.

/usr/share/applications/*desktop I'm not sure what it is for-- vimperator plugin? Something else? In general, snaps will want to ship these sorts of things themselves and/or use xdg-open, as mentioned.

/var/tmp/ is not allowed and the application should use the snap-specific TMPDIR (/tmp) instead. This is almost always non-fatal and shows up when the application is searching for a writable tmp area.

Since there are many different accesses being reported here all of which require changes to the snap or already have other bugs, I'm going to takeover this bug for the user namespace request.

Thanks!

[Jamie Strandboge (jdstrand)]

The firefox snap is also affected by this.

[Olivier Tilloy (osomon)]

And so are snaps which embed oxide-qt.

[Jamie Strandboge (jdstrand)]

@Chad, where is the chromium-browser snapcraft.yaml (or a script to generate the snap)? I've been using your chrome one but since this was for chromium-browser, figured you had a different one.

@Olivier, where is the webbrowser-app snapcraft.yaml (or whatever you were embedding oxide-qt)?

[Jamie Strandboge (jdstrand)]

Since this bug was targeted for browsers I'm implementing a browser-support interface to support them. We may move the user namespace bits into a 'user-namespace-support' interface or similar, but I'd like to better understand what that would look like before implementing it.

[Jamie Strandboge (jdstrand)]

This is merged in trunk now.

[Jamie Strandboge (jdstrand)]

This was fixed in 2.12 and is available in xenial-updates.