Is /run/user/<UID>/.bubblewrap/ doesn't exist and couldn't be created
(as was the case on my system), bubblewrap falls back to
/tmp/.bubblewrap-<UID>/. Local attacker could exploit this to prevent
other users from running bubblewrap, for example:
getent passwd | cut -d: -f3 | xargs printf '/tmp/.bubblewrap-%d\n' | xargs touch
But it gets worse, because bubblewrap is happy to use existing
/tmp/.bubblewrap-<UID>/, even when the directory is owned by some else.
In the worst case, this could be exploited by a local user to execute
arbitrary code in the container. (Though I couldn't find any way to
exploit this without disabling protected_symlinks.)
Created bubblewrap tracking bugs for this issue:
Affects: epel-7 [bug 1695965]
Affects: fedora-all [bug 1695964]
Github release https://github.com/projectatomic/bubblewrap/releases/tag/v0.3.3 just went out with the bugfix for https://github.com/projectatomic/bubblewrap/issues/304
RPM build is pending on bohdi now: https://bodhi.fedoraproject.org/updates/bubblewrap-0.3.3-2.el7
Tower is not affected since systemd-logind is used by default and the UID under /run/user/ is pre-created before bubblewrap service starts.
(In reply to Borja Tarraso from comment #5)
> Tower is not affected since systemd-logind is used by default and the UID
> under /run/user/ is pre-created before bubblewrap service starts.
This is incorrect; the system user using bubblewrap is not using a login session.
That being said, it would require local system access to try to exploit, which the vast majority of users should not have.
Setting Attack Complexity(AC) to High(H) as for an attack to be successful fs.protected_symlinks sysctl should be 0, which is not the case by default on Red Hat Enterprise Linux.
The attack also requires the path /run/user/<uid>/.bubblewrap to not exist, to be inaccessible or the program to fail when trying to create it. Normally, this directory either already exists or it is under the user control and it can be safely created by bubblewrap.