See https://bugzilla.kernel.org/show_bug.cgi?id=137351
Reported-by: Laurent Georget <laurent.georget@supelec.fr>
Reported-by: Ivan Kharpalev <ivan.kharpalev@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
With respect to cgroups version 1, CAP_SYS_ADMIN in the user
namespace allows only *named* hierarchies to be mounted (and
not hierarchies that have a controller).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add some more details for Section 1 and 8 formatting.
Separate out formatting discussion into commands, functions,
and "general".
In part triggered by https://bugzilla.kernel.org/show_bug.cgi?id=121211
Reported-by: Josh Triplett <josh@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A few months after applying Andy Lutomirski's patch that documented
ambient capabilities, I found myself again asking a question
that I'd already once asked of Any. So, best to be more explicit
in the man page that setting/locking SECBIT_NO_CAP_AMBIENT_RAISE
is not required when using prctl(PR_SET_SECUREBITS) to create
a capabilities-only environment.
This was the 4 Dec 2015 reply from Andy to my question:
> In the capabilities(7) page tehre is the longstanding text:
>
> An application can use the following call to lock itself, and
> all of its descendants, into an environment where the only way
> of gaining capabilities is by executing a program with associ‐
> ated file capabilities:
>
> prctl(PR_SET_SECUREBITS,
> SECBIT_KEEP_CAPS_LOCKED |
> SECBIT_NO_SETUID_FIXUP |
> SECBIT_NO_SETUID_FIXUP_LOCKED |
> SECBIT_NOROOT |
> SECBIT_NOROOT_LOCKED);
>
> As far as I can estimate, no changes are needed here to include
> SECBIT_NO_CAP_AMBIENT_RAISE and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED
> in the above prctl() call, but could you confirm please?
Correct. I'll probably write up a patch to suggest that doing this is
a poor idea on a conventional distro, though, and I'll explain why. I
suppose than deleting this would be an option, too.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to dereference/readlink /proc/PID/ns/* symlinks is
governed by a PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
List the mount operations permitted by CAP_SYS_ADMIN in a
noninitial userns.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Having privilege in a user NS only allows privileged
operations on resources governed by that user NS. Many
privileged operations relate to resources that have no
association with any namespace type, and only processes
with privilege in the initial user NS can perform those
operations.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a concrete example of how the kernel checks capabilities in
an associated user namespace when a process attempts a privileged
operation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid listing all namespace types in a couple of places,
since such a list is subject to bit rot as the number
of namespace types grows.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk