bwrap: capabilities support #101

Open
wants to merge 6 commits into
from

Projects

None yet

5 participants

@giuseppe
Member

a few patches that modify how bubblewrap works in privileged mode to allow execution of systemd:

https://asciinema.org/a/7gex3vdcumd1n72i3knstra2b

@alexlarsson
Member

Allowing a fresh mount of sysfs is a potential security leak. Sysadmins and containment system generally cover parts of /sys in order to not allow the unprivileged user access to them. Mounting a new instance will override this.

Can't we use a bind mount here instead?

bubblewrap.c
+ | CAP_TO_MASK (CAP_DAC_OVERRIDE) | CAP_TO_MASK(CAP_SETFCAP) | CAP_TO_MASK(CAP_SETPCAP) \
+ | CAP_TO_MASK (CAP_SETGID) | CAP_TO_MASK (CAP_SETUID) | CAP_TO_MASK (CAP_MKNOD) | CAP_TO_MASK (CAP_CHOWN) \
+ | CAP_TO_MASK (CAP_FOWNER) | CAP_TO_MASK (CAP_FSETID) | CAP_TO_MASK (CAP_KILL) \
+ | CAP_TO_MASK (CAP_SYS_CHROOT))
@alexlarsson
alexlarsson Oct 3, 2016 Member

Adding CAP_DAC_OVERRIDE here is vastly increasing the risk of having bubblewrap setuid. The whole reason we're doing this dance where we're only saving the caps we need for setting up the sandbox but running as the final user is that we can then be reasonably sure that the things that end up in the final sandbox is what the original user can access.

If the setup is run with DAC_OVERRIDE, then any source path you specifiy will be read with root privileges, which will let regular users access root-only files.

bubblewrap.c
+static uint32_t requested_caps[2] = {BASE_CAPS0, BASE_CAPS1};
+
+/* low 32bit caps needed */
+#define REQUIRED_SETUP_CAPS_0 (BASE_CAPS0 | CAP_TO_MASK (CAP_NET_ADMIN) | CAP_TO_MASK (CAP_SYS_ADMIN))
@alexlarsson
alexlarsson Oct 3, 2016 Member

You dropped CHROOT, SETUID and SETGID from REQUIRED_CAPS. These are needed for chroot() and user namespaces to work in the setup.

@giuseppe
giuseppe Oct 3, 2016 Member

they are coming from BASE_CAPS0

bubblewrap.c
@@ -408,17 +421,16 @@ acquire_caps (void)
/* Drop root uid, but retain the required permitted caps */
if (setuid (getuid ()) < 0)
die_with_error ("unable to drop privs");
+ did_setuid = TRUE;
@alexlarsson
alexlarsson Oct 3, 2016 Member

This approach means the file-caps based version of bwrap doesn't work. Although honestly, thats kinda usless vs setuid as it needs cap_sysadmin anyway.

bubblewrap.c
- data[1].effective = REQUIRED_CAPS_1;
- data[1].permitted = REQUIRED_CAPS_1;
- data[1].inheritable = 0;
+ data[0].effective = caps0;
@alexlarsson
alexlarsson Oct 3, 2016 edited Member

Don't you need to set permitted?

bubblewrap.c
if (capset (&hdr, data) < 0)
die_with_error ("capset failed");
+
+ if (prctl (PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0)
+ die ("could not set no new privs");
}
@alexlarsson
alexlarsson Oct 3, 2016 Member

Why this? We already do this in main()

bubblewrap.c
+ if (opt_unshare_user)
+ {
+ caps0 |= CAP_TO_MASK (CAP_CHOWN) | CAP_TO_MASK(CAP_SETUID) | CAP_TO_MASK (CAP_SETGID) | CAP_TO_MASK (CAP_FOWNER) | CAP_TO_MASK (CAP_DAC_OVERRIDE);
+ }
@alexlarsson
alexlarsson Oct 3, 2016 Member

I don't understand why you want the sandbox to have these capabilities by default just because some namespace is enabled. For instance, DAC_OVERRIDE means that a file that is read-only to you is still readable, no? That seems very unexpected.
Overall, this seems quite risky.

@giuseppe
giuseppe Oct 3, 2016 Member

thanks for the rewiew. Yes, this patch series is risky (and some parts too hacky), so I wanted to share my work in progress so to get comments before I spend more time on it.

IIUIC, even with DAC_OVERRIDE, the container should not be able to access files owned by users that have no mapping in the container user namespace. The only users that get a mapping in the container namespace are the uid of the user using bwrap and the range 10000-10999.

@alexlarsson
alexlarsson Oct 3, 2016 Member

Are you sure about that? Anyway, you still automatically grant the process properties that it wouldn't have if it were run with that capabilities. For instance if the user is "1000" it can now write to a file owned by user 1000 which is not marked with "u+w" permissions.

+ }
+ line3 = xasprintf ("%d %d 1\n", sandbox_id, parent_id);
+ return strconcat4 (line1, line2, line3, line4);
+}
@alexlarsson
alexlarsson Oct 3, 2016 Member

This breaks any use of non-privileged user namespaces use, because that only allows a single mapping.

@alexlarsson
Member

Overall, this patch series seems very risky to me. It would need very thorough review to make sure it doesn't make it possible to gain increased privileges for non-root users.

bubblewrap.c
}
if (is_privileged)
{
+ uint32_t caps0 = REQUIRED_SETUP_CAPS_0 | requested_caps[0];
@cgwalters
cgwalters Oct 3, 2016 Member

Isn't this a huge security hole if bubblewrap is installed setuid? I think we should be verifying whether getuid() == 0 or so.

@alexlarsson
alexlarsson Oct 3, 2016 Member

is_privileged means "we're not using user namespaces" in the code, not that we're initially launched by root.
The reason its doing this check instead of comparing effective uid is to also support filesystem caps instead of setuid.

@giuseppe giuseppe referenced this pull request in systemd/systemd Oct 4, 2016
Merged

[RFC] run systemd in an unprivileged container #4280

@cgwalters
Member

You could probably break out the "--no-reaper" as a separate PR, it looks safe to merge now, separately from higher risk changes.

@giuseppe giuseppe changed the title from [RFC] Privileged systemd to bwrap: capabilities support Oct 18, 2016
@giuseppe
Member

I have done some simplifications:

  1. the root user is not treated differently than other users.
  2. --cap-add supports only a subset of caps, which are safe to use in the sandbox.
  3. by default, do not leave any cap in the process.
  4. fix the FILECAPS mode.
  5. now --sys uses a bind mount to /sys.
  6. The additional uids/gids to use in the userns are read from /etc/subuid and /etc/subgid, the same conf files are used by newgidmap and newuidmap.

I had a discussion with Eric Biederman about enabling setgroups, he said that it is safe to enable setgroups when there is a mapping for the user in /etc/subuid, as there shouldn't be any mapping on a system where negative groups privileges are used (w.r.t CVE-2014-8989). I have not done this in the patch set yet, and I preferred to leave it as it is for now.
My suggestion to address this issue was to add a third mode "shadow" to /proc/self/setgroups so that the groups that were present on the userns creation could not be dropped. This is more invasive as it requires changes in the kernel: https://github.com/giuseppe/linux/tree/proc-setgroups-shadow.
Not a big issue anyway, as the systemd changes got merged and now it treats setgroups (0, NULL) as a warning.

I've also dropped CAP_AUDIT_*, as systemd will detect when these caps are not available and not error out.

@giuseppe
Member

Is there anything left before we can start reviewing this PR?

@alexlarsson
Member

Can you give a highlevel overview of the security aspects of this? I mean, what are you exposing and how is it safe to give that to unprivileged users?

For instance it seems to me that this relies on user namespaces to contain things, and given the discussion in #107 it seems like if the goal is to give out "a safe subset of user-namespace-like functionallity" then we can't actually use user namespaces at all in the setuid version of bwrap (due to the ptrace issue).

@giuseppe
Member

there are basically two big changes introduced by this series:

  1. we don't map only a single user in the new user namespace, but a range of them. This is needed so that systemd will be able to use users with uid < 1000 in the new user namespace. Those are mapped to some high values in the parent namespace. If the file /etc/subuids (the same file used by newuidmap) is present, then the range specified there is used.

  2. we leave some caps in the sandbox, user namespaces restricts what users are available so that caps like CAP_SETGID, CAP_SETUID (and all of those which are in the ALLOWED_CAPS0_UNSHARE_USER mask) allows to use only uids/gids that have a mapping in the new namespace. In this namespace only the parent uid/gid + a range of high uids/gids have a mapping, so making not possible to switch to some other user in the parent namespace.

With this new patchset, bubblewrap needs to keep CAP_DAC_OVERRIDE as that can be required in the user namespace, this makes possible to drop completely the need of PR_SET_DUMPABLE, I have added a patch that does it.

@alexlarsson
Member

If you have CAP_DAC_OVERRIDE you can use bubblewrap to overwrite /etc/passwd with something like:

--bind / / --file some-fd /etc/passwd

Doesn't seem very safe...

@giuseppe
Member

we drop all the caps in the unprivileged setup process, so that should not happen no?

I get this:

$ echo hi | bwrap --unshare-user --unshare-pid --unshare-net --cap-add ALL --bind / / --file 0 /etc/passwd echo done
Can't create file /etc/passwd: Permission denied
Invalid size 0 from unprivileged helper

@alexlarsson
Member

Ah, that is true, I think its still unsafe though due to the ptrace hole discussed in the above link.
As soon as you clone NEW_USER the child is ptraceable by users in the parent namespace. If this process has DAC_OVERRIDE, can't you then make it do whatever it wants?

Honestly, i'm not sure what the sematics of DAC_OVERRIDE is in a user namespace...

@giuseppe
Member

the only risk I see happens if ptrace could be exploited before the uid_map/gid_map are in place.
I didn't expect that it would be possible to ptrace a process in a new user namespace even before the uid_map is set.

To avoid the problem altogether, I've added another patch that changes the uid of the process back to 0 until the uid_map file is written, basically locking ptrace from non root users until the user mapping is in place.

Once that is done, it is not possible to write a new map file and all the caps are restricted to the users defined in the user namespace, so that won't be an issue with DAC_OVERRIDE as well. DAC_OVERRIDE is restricted to the users in the namespace. If an user has no mapping in the new user namespace, then it will fail with EPERM.

@alexlarsson
Member

There is still a fundamental question about what bubblewrap provides here that we need to figure out. Lots of distros (including rhel7) disable user namespaces or make it only accessible by root, because the attack surface for user namespaces is so large (see e.g. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3135).

The story so far is that we expose only a subset of the user namespace operations, which we deem safe (mainly bind mounts, etc), so it is safe to allow this setuid binary to run for everyone, even though everyone is not allowed use of user namespace.

However, due to the ptrace issue we're not really any more secure than a general user namespace, because bwrap can be attacked via ptrace to allow arbitrary code execution in the privileged-in-user-ns part of the setup, and bwrap could thus be used to attack e.g. the CVE above. This means that a setuid bwrap is essentially neutering the distro decision to limit user namespaces to root, which I think is a bad idea.

So, the question here is if we can use user namespaces at all...

@alexlarsson
Member

(And obviously, the present patch fully depends on user namespaces)

@alexlarsson
Member

@giuseppe Also, i'm not sure why having a uid of 0 disallows ptrace? The parent-user-namespace check seems to override everything to always allow ptrace.

@giuseppe
Member

@alexlarsson I had a look in the kernel to understand how the access is granted, the relevant code seems to be in __ptrace_may_access (ptrace.c):

    tcred = __task_cred(task);
    if (uid_eq(caller_uid, tcred->euid) &&
        uid_eq(caller_uid, tcred->suid) &&
        uid_eq(caller_uid, tcred->uid)  &&
        gid_eq(caller_gid, tcred->egid) &&
        gid_eq(caller_gid, tcred->sgid) &&
        gid_eq(caller_gid, tcred->gid))
        goto ok;
    if (ptrace_has_cap(tcred->user_ns, mode))
        goto ok;
    rcu_read_unlock();
    return -EPERM;

if I understand it correctly, the access is granted either if the process has CAP_SYS_PTRACE, or it has the same credentials as the target process.

I've tried adding a sleep between the raw_clone and in facts I could ptrace the container without the setuid trick. With the latest patch, I get an error when I try to ptrace the process.

@alexlarsson
Member

Oh, i see, the override with user namespaces is below, after the ok::

    if (dumpable != SUID_DUMP_USER &&
        !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
        rcu_read_unlock();
        return -EPERM;
    }

So, by running the privileged part as the real uid 0 we can avoid the ptrace issue, but then we risk running into filesystem access problems, because if we can somehow trick the privileged part into doing file i/o we will be doing the file lookups as root, not the user. The main reason I chose to run as the user was to guarantee that all file i/o we did (say --bind /etc/shadow /my/file) would have the permissions of the user.

However, we can probably avoid this issue by using fsuid == real user. Then we'll get file dac checks as per the actual user.

@alexlarsson
Member

i.e. I want the above --bind /etc/shadow /my/file to fail with EPERM on sandbox startup, not later from accessing /my/file.

@giuseppe
Member

I get the same behaviour with the current bubblewrap:

$ bwrap --bind / / --tmpfs /tmp --bind /etc/shadow /tmp/shadow cat /tmp/shadow
cat: /tmp/shadow: Permission denied
@alexlarsson
Member

I guess bind mounts don't need Open rights. But at least you can't e.g. mount a readable-by-the-user file from inside a readable-by-the-user directory, right?

@alexlarsson
Member

Eh, readable-only-by-root dir I mean

@giuseppe
Member

hmm. I just checked that and it will work in the same way. In the patch, only the write_uid_gid_map part is done with setuid (0), once the map is written, then the original uid is restored. All the mounts are done after that, where the uid is already the one of the user using bubblewrap.

@alexlarsson
Member

@giuseppe Ah, but in that model as soon as you drop back from uid0 you're ptracable again, and yes, the uid map may neuter DAC_OVERRIDE, but you still have all sort of other permissions in the user namespace that you can exploit (such as CVE-2016-3135, which just needed CAP_NET_ADMIN).

So, basically, in order to support even a basic (ignoring this patch-set) version of bwrap safely that has user namespaces support I think the only realistic approach is to always run the privileged part of the sandbox setup as (real) uid 0 to avoid ptraceability, but with fsuid=user uid to avoid being able to access files with as-uid-0 permissions. That would let us honestly say what the readme does:

Bubblewrap could be viewed as setuid implementation of a subset of user namespaces. Emphasis on subset - specifically relevant to the above CVE, bubblewrap does not allow control over iptables.

But, once we go beyond just fixing what bubblewrap does today, if we let the sandbox retain capabilities in the user namespace, even if there is some uid/gid remapping, then we can't really claim the above anymore. Basically we'd be overriding the decision of the distro to disable user namespaces in general for non-root. I'm not sure that is a good idea?

@giuseppe
Member

is there a centralized option to enable/disable unprivileged user namespaces? We could be conservative and use them only when explicitly enabled, and it won't be the default. I agree that this patch set might expose more security issues, but on the other hand, the alternative is to run a container as root, which won't be safer than this.

@alexlarsson
Member

It varies from distro to distro. There is no way upstream (but its been proposed), but some distros have sysctls that let you enable it. We could hook of something like that.

@alexlarsson
Member

@cgwalters Do you have an opinion here?

@giuseppe
Member

@alexlarsson @cgwalters honoring /proc/sys/kernel/unprivileged_userns_clone would be fine?

@alexlarsson
Member

@giuseppe That is not available on my F24 kernel. I know it is in debian jessie. Is it in rhel?

But anyway, if that is available and set to true, then clearly its fine to use it because anyone can use user-ns, no setuid required at all.

@giuseppe
Member

I've not found anything present for Fedora, so I thought we could use that, as anyway if it is set, it was explicitly requested. I'll investigate better if something exists for Fedora.

@giuseppe
Member

After looking into it, I am not sure proc/sys/kernel/unprivileged_userns_clone would be the right thing to do, we can add this check but for now I've changed the patch set to allow user namespaces only when the user is explicitly allowed in the /etc/subuid and /etc/subgid files. These are the same configuration files used by newuidmap and Docker 1.10 for its user namespaces. While Docker is used by root, so it is not exactly the same thing, newuidmap is a setuid program, which makes it somehow similar to this use case.

@alexlarsson
Member

That makes a lot of sense to me. I mean, the entire thing hinges on being allowed to use some subset of uids anyway, right? We can't just grab a range and use it, because it may conflict with other use on the machine.

@giuseppe
Member

yes exactly. I dropped completely the patch that would set "to some random high uids/gids" and rely completely on what is defined in the /etc/sub{uid,gid} files.

@alexlarsson
Member

So, newuidmap is setuid, allowing it to write to the uid_map and extend the user namespace uid-mapping in ways which would otherwise not be allowed by the kernel support for unprivileged user namespaces. That makes sense, because these are root-owned files that defines the access. Using these files in a setuid app that actually creates user namespaces is a bit different though, because it additionally allows you to create such a user namespace and retain capabilities in it.

So, it does let the sysadmin control who can do this, but it also increases the security risk of adding a user to /etc/subuid. Is this ok? Maybe, but at the very least it needs to be clearly messages. @cgwalters opinions?

@giuseppe
Member

I had a private conversation with Eric Biederman about this and he suggested me to use these two files for the configuration of the user namespaces and also to check whether setgroups is permitted, since a system that uses negative file permissions should not allow an user in /etc/subgid.

We could make it even stricter, I didn't find any place where this setting could be stored, /proc/sys/kernel/unprivileged_userns_clone seems to have a different meaning and would be better to not expect it to be set in order to use the bubblewrap features.

@alexlarsson
Member

Is reading /etc/subgid in an unprivileged helper really right? I mean, you'll be doing root-trusting operations on the result of this, and if is running as the user, he could be ptracing it and modifying the result.

@alexlarsson
Member

Anyway, before looking in depth on this series I want to fix the current problems we have wrt ptrace and user namespaces so we have a "proper" secure (i.e. doesn't trust user namespaces) release.

@giuseppe
Member
giuseppe commented Nov 7, 2016

the user process is not ptraceable as it keeps these uids (from /proc/self/status):

Uid:    1000    0   0   1000
Gid:    1000    0   0   1000

I am doing it from a separate process just to keep the parsing as non root, but I think it should be fine to run it as root as well.

I have just pushed an updated version for the last patch, as this patch in the kernel broke this feature on the latest Fedora kernel (4.8.4-200.fc24.x86_64):

commit 036d523641c66bef713042894a17f4335f199e49
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Jul 1 12:52:06 2016 -0500

    vfs: Don't create inodes with a uid or gid unknown to the vfs

    It is expected that filesystems can not represent uids and gids from
    outside of their user namespace.  Keep things simple by not even
    trying to create filesystem nodes with non-sense uids and gids.

    Acked-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
@rh-atomic-bot

☔️ The latest upstream changes (presumably b48c129) made this pull request unmergeable. Please resolve the merge conflicts.

@cgwalters
Member
cgwalters commented Nov 10, 2016 edited

Can you split this PR up into:

  1. Fixes (first two commits and the last)
  2. Non-security related features (--no-reaper and potentially --sys)
  3. Security-related features (the --cap-add)

Or something like that? The thing is again that if we apply this series as is now, Debian users of flatpak will again be exposed to most of the userns attack surface, because they'll be able to retain full privileges there (such as CAP_NET_ADMIN and hence be able to create iptables rules).

In general, given that we only support the host netns or a new one, but we don't support creating a bridge device or whatever between them, how could someone actually use --cap-add CAP_NET_ADMIN really usefully even, since you'll be disconnected from the host and hence the internet?

@cgwalters
Member

I'd like to see a bit more rationale in each commit message. The commit adding --sys doesn't say why we're adding this new API. I'm pretty sure it's for systemd - but can we say that in the commit?

@cgwalters
Member

Also, can you add a demos/systemd.sh?

@giuseppe
Member

I have created a new PR with the fix commits here:

#117

@giuseppe
Member

I've pushed a new version with:

  • demo for running a systemd container
  • dropped CAP_NET_ADMIN, since it is not useful at the moment
  • dropped the separate process for parsing the additional uids and gids for an user
@rh-atomic-bot

☔️ The latest upstream changes (presumably 3e65988) made this pull request unmergeable. Please resolve the merge conflicts.

@giuseppe
Member

would this feature be accepted if we require that it must be enabled via some settings in /etc?

@alexlarsson
Member

I'm so sorry I've not commented on this in a long time. I've been (and still am) super busy with other stuff. I have three overall issues with this feature, first of all it is a large change in how the capabilities are handled which need very serious review to make sure it doesn't accidentally leave open any security holes. Secondly, it significantly weakens the stance that bubblewrap is "safer" than unprivileged user namespaces (which many people don't trust). Of course, having a way to configure this on a per-user basis (defaulting to off) makes this less of a problem. And third, its fundamentally relying on user namespaces, which makes this feature less widely usable than the rest of bubblewrap.

That said, this is not a NACK, just an excuse me for not having had time to look at this.

@cgwalters
Member

I think we can assume by the time the "next round" of LTS/enterprise OSes/distros roll around, unpriv userns will be broadly accessible. The question is - in the meantime, what are the use cases for greater capabilities?

The "systemd-in-bwrap" case that was motivating here required a number of patches to systemd, which I'm assuming aren't in the Docker base images for these respective LTS versions. Will we suggest people use e.g. Fedora base images on e.g. CentOS7 with this? Or are we thinking we'll get the systemd changes backported?

@giuseppe
Member

I'd say for the time being it would be fine to suggest to use Fedora for running containers with systemd as non privileged user.

The ultimate goal is to run the same image either as system container, or user container when possible. atomic has some basic support for --user, and for example the etcd container can run through runc or via bwrap-oci/bubblewrap (at least last time I've tried that).

systemd in a runc container itself is still work in progress (there is only one image that I know of using it: https://github.com/pschiffe/gce-system-container), and even this requires upstream version for oci-systemd-hook and oci-register-machine, but hopefully we'll soon better support it.

Most of the logic that for docker/runc containers is in the oci-systemd-hook and oci-register-machine hooks must be duplicated in bwrap-oci. When it detects the image is using systemd, it will setup all the needed configuration for the systemd container.

Alternatively, there is some work going on for runc as well for supporting rootless containers that should be considered for atomic install --user:

opencontainers/runc#774

@rhatdan any opinions on this?

@cyphar
Contributor
cyphar commented Dec 30, 2016

@alexlarsson

You might be aware of this, but there is a patch proposed to fix the ptrace hole you are referring to. I'm not sure if it'll get merged (it breaks userspace), but if it does then joining containers will finally be safe again. Currently I'd recommend being very cautious around code which involves setns.

@cgwalters

I think we can assume by the time the "next round" of LTS/enterprise OSes/distros roll around, unpriv userns will be broadly accessible.

I believe the only current enterprise OS that has unpriv user namespaces support is SUSE Linux Enterprise. I've been personally having a lot of issues trying to get rootless containers (within runC) to work on old Scientific Linux distributions (some people at CERN were quite interested in using them for computing jobs). 😢

@rh-atomic-bot

☔️ The latest upstream changes (presumably a6e1516) made this pull request unmergeable. Please resolve the merge conflicts.

giuseppe added some commits Sep 23, 2016
@giuseppe giuseppe bubblewrap: add --no-reaper
Useful to run a process with PID=1

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
d6a5b89
@giuseppe giuseppe bubblewrap: add --sys DEST to mount sysfs
Add a shortcut to bind mount /sys to the specified destination.
Having access to /sys is required for images which are using systemd.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
10d8a54
@giuseppe giuseppe bubblewrap: add --cap-add and --cap-drop
When using namespaces, permit to leave some capabilities in the
sandbox.  This can be helpful to run a system instance of systemd.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
d008292
@giuseppe giuseppe bubblewrap: no privileged userns if not permitted by /etc/sub{uid,gid}
disable privileged user namespace usage if the user is not enabled in
the /etc/subuid and /etc/subgid files.

If the user is present, then use the configuration in those files to
read the range of users that is possible to use in the new namespace.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
9f767a8
@giuseppe giuseppe bubblewrap: do not block setgroups if the user is in /etc/subgid
If the user has an explicit additional groups mapping in the
/etc/subuid file, then it is safe to use setgroups.
When negative groups permission are in place (which may lead to
CVE-2014-8989), the /etc/subuid file should not allow an user to be
listed there.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
901233c
@giuseppe giuseppe demos: add a demo for running a container using systemd
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
b9a112c
@cgwalters cgwalters referenced this pull request Jan 31, 2017
Open

WIP: Keepcaps #172

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment