Commit Graph

6 Commits

Author SHA1 Message Date
Serge Hallyn
f93cf255d4 Update licensing info
Closes #238

Update all files to list SPDX license shortname.  Most files are
BSD 3 clause license.

The exceptions are:

serge@sl ~/src/shadow$ git grep SPDX-License | grep -v BSD-3-Clause
contrib/atudel:# SPDX-License-Identifier: BSD-4-Clause
lib/tcbfuncs.c: * SPDX-License-Identifier: 0BSD
libmisc/salt.c: * SPDX-License-Identifier: Unlicense
src/login_nopam.c: * SPDX-License-Identifier: Unlicense
src/nologin.c: * SPDX-License-Identifier: BSD-2-Clause
src/vipw.c: * SPDX-License-Identifier: GPL-2.0-or-later

Signed-off-by: Serge Hallyn <serge@hallyn.com>
2021-12-23 19:36:50 -06:00
Serge Hallyn
8492dee663 subids: support nsswitch
Closes #154

When starting any operation to do with subuid delegation, check
nsswitch for a module to use.  If none is specified, then use
the traditional /etc/subuid and /etc/subgid files.

Currently only one module is supported, and there is no fallback
to the files on errors.  Several possibilities could be considered:

1. in case of connection error, fall back to files
2. in case of unknown user, also fall back to files

etc...

When non-files nss module is used, functions to edit the range
are not supported.  It may make sense to support it, but it also
may make sense to require another tool to be used.

libsubordinateio also uses the nss_ helpers.  This is how for instance
lxc could easily be converted to supporting nsswitch.

Add a set of test cases, including a dummy libsubid_zzz module.  This
hardcodes values such that:

'ubuntu' gets 200000 - 300000
'user1' gets 100000 - 165536
'error' emulates an nss module error
'unknown' emulates a user unknown to the nss module
'conn' emulates a connection error ot the nss module

Changes to libsubid:

Change the list_owner_ranges api: return a count instead of making the array
null terminated.

This is a breaking change, so bump the libsubid abi major number.

Rename free_subuid_range and free_subgid_range to ungrant_subuid_range,
because otherwise it's confusing with free_subid_ranges which frees
    memory.

Run libsubid tests in jenkins

Switch argument order in find_subid_owners

Move the db locking into subordinateio.c

Signed-off-by: Serge Hallyn <serge@hallyn.com>
2021-04-16 21:02:37 -05:00
Christian Brauner
52c081b02c
new{g,u}idmap: align setuid and fscaps behavior
Commit 1ecca8439d ("new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS")
does contain a wrong commit message, is lacking an explanation of the
issue, misses some simplifications and hardening features. This commit
tries to rectify this.

In (crazy) environment where all capabilities are dropped from the
capability bounding set apart from CAP_SET{G,U}ID setuid- and
fscaps-based new{g,u}idmap binaries behave differently when writing
complex mappings for an unprivileged user:

1. newuidmap is setuid

unshare -U sleep infinity &
newuidmap $? 0 100000 65536

First file_ns_capable(file, ns, CAP_SYS_ADMIN) is hit. This calls into
cap_capable() and hits the loop

for (;;) {
        /* Do we have the necessary capabilities? */
        if (ns == cred->user_ns)
                return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;

        /*
         * If we're already at a lower level than we're looking for,
         * we're done searching.
         */
        if (ns->level <= cred->user_ns->level)
                return -EPERM;

        /*
         * The owner of the user namespace in the parent of the
         * user namespace has all caps.
        */
        if ((ns->parent == cred->user_ns) && uid_eq(ns->owner, cred->euid))
                return 0;

        /*
         * If you have a capability in a parent user ns, then you have
         * it over all children user namespaces as well.
        */
        ns = ns->parent;
}

The first check fails and falls through to the end of the loop and
retrieves the parent user namespace and checks whether CAP_SYS_ADMIN is
available there which isn't.

2. newuidmap has CAP_SETUID as fscaps set

unshare -U sleep infinity &
newuidmap $? 0 100000 65536

The first file_ns_capable() check for CAP_SYS_ADMIN is passed since the
euid has not been changed:

if ((ns->parent == cred->user_ns) && uid_eq(ns->owner, cred->euid))
        return 0;

Now new_idmap_permitted() is hit which calls ns_capable(ns->parent,
CAP_SET{G,U}ID). This check passes since CAP_SET{G,U}ID is available in
the parent user namespace.
Now file_ns_capable(file, ns->parent, CAP_SETUID) is hit and the
cap_capable() loop (see above) is entered again. This passes

if (ns == cred->user_ns)
        return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;

since CAP_SET{G,U}ID is available in the parent user namespace. Now the
mapping can be written.

There is no need for this descrepancy between setuid and fscaps based
new{g,u}idmap binaries. The solution is to do a
seteuid() back to the unprivileged uid and PR_SET_KEEPCAPS to keep
CAP_SET{G,U}ID. The seteuid() will cause the
file_ns_capable(file, ns, CAP_SYS_ADMIN) check to pass and the
PR_SET_KEEPCAPS for CAP_SET{G,U}ID will cause the CAP_SET{G,U}ID to
pass.

Fixes: 1ecca8439d ("new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS")
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
2018-10-28 01:27:48 +02:00
Giuseppe Scrivano
1ecca8439d
new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS
if the euid!=owner of the userns, the kernel returns EPERM when trying
to write the uidmap and there is no CAP_SYS_ADMIN in the parent
namespace.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2018-10-22 16:57:50 +02:00
Nicolas François
e1a4b6e57b Document the semantic of ranges.
* libmisc/idmapping.h: Document what the upper and lower fields
	are in struct map_range.
	* man/newgidmap.1.xml: Document when the gid, gidlower and count
	argument are.
	* man/newuidmap.1.xml: Likewise for uid, uidlower and count.
2013-08-13 19:28:07 +02:00
Eric W. Biederman
673c2a6f9a newuidmap,newgidmap: New suid helpers for using subordinate uids and gids
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
2013-08-05 10:08:46 -05:00