buildstream-migration / bst-staging

GNU Lesser General Public License v2.1
0 stars 0 forks source link

`bst-here` capabilities are too narrow #156

Open Cynical-Optimist opened 4 years ago

Cynical-Optimist commented 4 years ago

See original issue on GitLab In GitLab by [Gitlab user @tlater] on Nov 15, 2017, 18:08

Currently bst-here runs docker only with CAP_SYS_ADMIN, although bwrap also explicitly requires CAP_SYS_CHROOT, CAP_NET_ADMIN, CAP_SETUID and CAP_SETGID for various purposes. Adding these permissions does not seem to be enough, however, presumably there are some permissions bwrap needs that it doesn't check for explicitly.

This causes errors when bwrap attempts to mount system directories. A test case that mimics what buildstream runs internally for example is:

/src> bwrap --ro-bind / / --unshare-user --unshare-pid --proc /proc /bin/bash
Can't mount proc on /newroot/proc: Operation not permitted

When running docker with --privileged this is not an issue, since all capabilities are granted. We should find the capabilities that are required beyond the above and change the script to provide them.

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @hashpling] on Nov 21, 2017, 16:29

I wonder why bwrap needs CAP_SYS_CHROOT, I thought it used pivot_root or is that controlled by the same capability - the documentation I read suggests that CAP_SYS_ADMIN is needed to use pivot_root?

pivot_root was definitely the first reason that I needed to add --security-opt seccomp=unconfined. If we were less lazy we could probably tighten this up with a custom seccomp profile.

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @tlater] on Nov 29, 2017, 10:44

mentioned in merge request !169

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @tlater] on Nov 29, 2017, 10:47

As a temporary measure !169 sets the default permissions for this to --privileged, since the script is otherwise broken. Obviously this is not a final solution, but we can mark this as an enhancement again when that lands.

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @dp0] on Apr 13, 2018, 16:59

This doesn't appear to be a capability issue (this can be verified by telling Docker to use the capability ALL). One thing that may be playing a role in this (or was for me, anyway) was not having pivot_root in my seccomp profile. After explictly whitelisting it in a custom profile and setting apparmor to be unconfined, all works as expected.

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @tlater] on Nov 29, 2019, 17:58

removed milestone