Based on a patch from Steven McDonald <steven@steven-mcdonald.id.au>:
This makes 'unshare --user' work correctly in the case where the user's
shell is provided by busybox itself.
'unshare --user' creates a new user namespace without any uid mappings.
As a result, /bin/busybox is setuid nobody:nogroup within the
namespace, as that is the only user. However, since no uids are mapped,
attempting to call setgid/setuid fails, even though this would do
nothing:
$ unshare --user ./busybox.broken ash
ash: setgid: Invalid argument
'unshare --map-root-user' still works, but because Linux only allows
uid/gid mappings to be set up once, creating a root mapping makes such
a namespace useless for creating multi-user containers.
With this patch, setgid and setuid will not be called in the case where
they would do nothing, which is always the case inside a new user
namespace because all uids are effectively mapped to nobody:
$ id -u
1000
$ ls -lh busybox.fixed
-rwsr-xr-x 1 root root 826.2K May 21 00:33 busybox.fixed
$ unshare --user ./busybox.fixed ash
$ id -u
65534
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"""
For example, given input file:
foo
bar
baz
after shuffling the input file, foo will never end up back on the first line.
This came to light when I ran into a use-case where someone was selecting
a random line from a file using shuf | head -n 1, and the results on busybox
were showing a statistical anomaly (as in, the first line would never ever
be picked) vs the same process running on environments that had gnu coreutils
installed.
On line https://git.busybox.net/busybox/tree/coreutils/shuf.c#n56 it uses
r %= i, which will result in 0 <= r < i, while the algorithm specifies
0 <= r <= i.
"""
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some watchdog implementations may do things other than issue
a reboot on a watchdog timeout. In this case, there's the
possibility of restarting this program from the state of
the watchdog device not being properly stopped (done by writing
a 'V' and closing the device). Since it wasn't stopped, the
driver may not be able to restart the watchdog when this program
reopens it and starts pinging it.
To fix this, the code will always first issue the stop when it
starts up.
function old new delta
shutdown_on_signal - 32 +32
watchdog_main 268 298 +30
shutdown_watchdog - 25 +25
watchdog_shutdown 41 - -41
------------------------------------------------------------------------------
(add/remove: 2/1 grow/shrink: 1/0 up/down: 87/-41) Total: 46 bytes
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
With Linux 4.3, a new set of capabilities has been introduced with the
ambient capabilities. These aim to solve the problem that it was
impossible to grant run programs with elevated privileges across
non-root users. Quoting from capabilities(7):
This is a set of capabilities that are preserved across an execve(2)
of a program that is not privileged. The ambient capability set
obeys the invariant that no capability can ever be ambient if it is
not both permitted and inheritable.
With this new set of capabilities it is now possible to run an
executable with elevated privileges as a different user, making it much
easier to do proper privilege separation.
Note though that the `--ambient-caps` switch is not part of any released
version of util-linux, yet. It has been applied in 0c92194ee (setpriv:
support modifying the set of ambient capabilities, 2017-06-24) and will
probably be part of v2.31.
function old new delta
parse_cap - 174 +174
setpriv_main 1246 1301 +55
.rodata 146307 146347 +40
static.setpriv_longopts 40 55 +15
packed_usage 32092 32079 -13
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The main use case of setpriv is to modify the current state of
privileges available to the calling process and spawn a new executable
with the modified, new state. Next to the already supported case of
modifying the no-new-privs flag, util-linux also supports to modify
capability sets.
This commit introduces to add or drop capabilities from the set of
inheritable capabilities. Quoting from capabilities(7):
This is a set of capabilities preserved across an execve(2).
Inheritable capabilities remain inheritable when executing any
program, and inheritable capabilities are added to the permitted set
when executing a program that has the corresponding bits set in the
file inheritable set.
As such, inheritable capabilities enable executing files with certain
privileges if the file itself has these privileges set. Note though that
inheritable capabilities are dropped across execve when running as a
non-root user.
function old new delta
getcaps - 237 +237
setpriv_main 1129 1246 +117
.rodata 146198 146307 +109
static.setpriv_longopts 29 40 +11
packed_usage 32107 32092 -15
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As with the previous commit, this commit introduces the ability to dump
the set of ambient capabilities.
function old new delta
setpriv_main 982 1129 +147
.rodata 146148 146198 +50
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As with the previous commit, this one implements the ability to dump the
capability bounding set.
function old new delta
setpriv_main 838 982 +144
.rodata 146101 146148 +47
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The setpriv executable from util-linux also dumps out information on the
different capability sets known by the kernel. By default, these are the
inheritable capabilities, bounding capabilities and (not yet released)
the ambient capabilities, which have been introduced with Linux 4.3.
This patch introduces the ability to dump the set of inheritable
capabilities.
By default, setpriv(1) identifies capabilities by their human-readable
name, for example 'net_admin'. For unknown capabilities, though, it does
instead use the capability's value, for example 'cap_12', which is
equivalent to 'net_admin'. As there is no kernel interface to retrieve
capability names by their index, we have to declare these ourselves,
which adds to setpriv's size.
To counteract, using the human-readble name has been made configurable.
The following sizes are with the 'FEATURE_SETPRIV_CAPABILITY_NAMES'
enabled:
function old new delta
.rodata 145969 146405 +436
setpriv_main 467 842 +375
capabilities - 304 +304
And with 'FEATURE_SETPRIV_CAPABILITY_NAMES' disabled:
function old new delta
setpriv_main 467 838 +371
.rodata 145969 146101 +132
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Introduce the ability to dump the state of the no-new-privs flag, which
states whethere it is allowed to grant new privileges.
function old new delta
setpriv_main 419 467 +48
.rodata 145926 145969 +43
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
makedevs_main 1056 1071 +15
Patch by Kang-Che Sung <explorer09@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
dpkg moved to away from dynamically allocating the hashtables in commit
c87339d584 (dpkg: trivial code shrinkage, and redo G trick correctly) almost
ten years ago, but the cleanup code was never adjusted to match.
Glibc loudly complains about this:
*** Error in `dpkg': free(): invalid pointer: 0x0000007fac3478c0 ***
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
setpriv from util-linux has an option to dump the current state
regarding privilege settings via '--dump'. It prints out information on
the real and effective user and group IDs, supplementary groups, the
no-new-privs flag, the capability sets as well as secure bits.
This patch is the start of supporting this mode. To make introduction of
the '--dump' easier to reason about, its introduction has been split
into multiple patches. This particular one introduces the ability to
print out user and group information of the current process.
function old new delta
setpriv_main 89 322 +233
getresuid - 41 +41
getresgid - 41 +41
static.setpriv_longopts 22 29 +7
packed_usage 31675 31669 -6
------------------------------------------------------------------------------
(add/remove: 4/0 grow/shrink: 2/1 up/down: 322/-6) Total: 316 bytes
Patch by Patrick Steinhardt <ps@pks.im>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The current option parsing logic of setpriv only supports the case where
we want to execute a sub-program and have at most one argument. Refactor
handling of options to solve these shortcomings to make it easy to
support 'setpriv --dump', which does not accept any additional
arguments, as well as the case where additional options are passed to
setpriv. This is done by handling 'argc' ourselves, throwing an error
when no program is specified, as well as introducing an enum for the
different option bitmasks.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
By default, the 'getopt32' call will continue parsing the command line
even after hitting a non-option string. But in setpriv, this should be
avoided, as all parameters following the initial non-option argument are
in fact arguments to the binary that is to be executed by setpriv.
Otherwise, calling e.g. 'busybox setpriv ls -l' would result in an error
due to the unknown parameter "-l".
Fix the issue by passing "+" as the first character in the options
string. This will cause 'getopt32' to stop processing after hitting the
first non-option.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
