When a process uses the syscall `prctl(PR_SET_PDEATHSIG, ...)`, it will
get notified with a process-defined signal as soon as its parent process
dies. This is for example being used by unshare(1)'s recently added
"--kill-child" option, causing the forked child to be killed as soon as
unshare itself dies.
Unfortunately, some LSMs will cause the parent death signal to be reset
when a process changes credentials, with the most important ones being
SELinux and AppArmor. The following command will thus not work as
expected:
unshare --fork --kill-child setpriv --reuid user <executable>
As soon as setpriv changes UID, the parent death signal is cleared and
the child will never get signalled when unshare gets killed.
Add a new option "--pdeathsig keep|clear|<signal>". Setting this flag
will cause us to either
- restore the previously active parent death signal as soon as the
setpriv has applied all credential changes
- clear the parent death signal
- set the parent death signal to "<signal>"
Furthermore, print out the currently set signal when dumping process
state.
[kzak@redhat.com: - small changes in codding style]
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Karel Zak <kzak@redhat.com>
When setting capabilities, we accept human readable names like for
example `sys_rawio` or `net_admin`. To do so the translation between the
capability name and its in-kernel index, we rely on the function
`capng_name_to_capability`. When the function does not know the named
capability, it will return an error value and we abort setting the
capability.
This relies upon the ability of libcap to know all capabilities inside
of the kernel. But actually, it is possible that new capabilities are
introduced inside of the Linux kernel which are not recognized yet by
the library. When dumping these unknown capabilities, libcap will simply
return a string like "cap_38", that is it will append the capability's
in-kernel index to the prefix "cap_". This may lead a user to also think
that "cap_38" may be passed to the switches "--inh-caps" or
"--ambient-caps", which is unfortunately not the case.
We can do better here by instead accepting strings in the form of
"cap_N". To do so, we can simply rely on the fact that capability
indices are steadily increasing and that the highest index known to the
kernel is stored inside of the kernel's procfs, made readily available
by our function `real_cap_last_cap()`. So in case libcap does not know a
capability name, we can simply parse the string and, if it is in the
correct format, check whether the detected index is between 0 and the
highest capability index. If so, we can treat it as a valid capability
string and apply it.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
This got lost in 30129e2f
sys-utils/setpriv.c:182:32: warning: implicit conversion from enumeration type
'enum cap_type' to different enumeration type 'capng_type_t'
[-Wenum-conversion]
return capng_have_capability(which, i);
~~~~~~~~~~~~~~~~~~~~~ ^~~~~
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
changed in include/c.h and applied via sed:
sed -i 's/fprintf.*\(USAGE_MAN_TAIL.*\)/printf(\1/' $(git ls-files -- "*.c")
sed -i 's/print_usage_help_options\(.*\);/printf(USAGE_HELP_OPTIONS\1);/' $(git ls-files -- "*.c")
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Right now, we do not support modifying the set of ambient capabilities,
which has been introduced quite recently with Linux 4.3. As libcap-ng
does not yet provide any ability to modify this set, we do have to roll
our own support via `prctl`, which is now easy to do due to the
indirections introduced in the preceding commits. We add a new command
line argument "--ambient-caps", which uses the same syntax as both
"--inh-caps" and "--bounding-set" to specify either adding or dropping
capabilities.
This commit also adjusts documentation to mention the newly introduced
ability to modify the ambient capability set.
Based on a patch by Andy Lutomirski.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Our code dumping owned capabilities does not yet handle ambient
capabilities, which were only recently introduced with Linux 4.3. This
commit implements printing ambient capabilities if they're supported by
the system.
Based on a patch by Andy Lutomirski.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
libcap-ng provides a function to update capabilities with
`capng_update`. As libcap-ng has not yet been updated to enable
modification of ambient capabilities, we cannot use it to update this
set, though. In order to allow easily extending the logic to also handle
ambient capability sets, we create a new function `cap_update`. Right
now, it simply calls out to `capng_update` for all supported capability
types.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
The loop in `print_caps` iterates over every capability, checks whether
it is set and, if so, prints out its name. Currently, the checking and
printing is rather intertwined, making it harder to extend the check
whether we own a capability.
Prepare code for the introduction of ambient capabilities by
disentangling the code checking for a capability and printing code. A
new function `has_cap` is introduced and `print_caps` will now simply
call out to it and only handle printing itself. This easily allows to
extend the capability check based on which capability set is queried.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
The capng_type is used to distinguish the different types of capability
sets, that is the effective, inheratibale, permitted capabilities as
well as the capability bounding set. In Linux 4.3, a new set of
capabilities was introduced with ambient capabilities. Unfortunately,
libcap-ng does not provide any support for these kind of capabilities
and as such, we will have to roll our own support.
As a first step, we introduce an indirection for the `capng_type` enum,
allowing us to add the ambient capability type later on. Right now, no
functional change is expected from this change and in fact, each of the
newly introduce enums should have the same value as respective enum of
libcap-ng.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Consolidate --help and --version descriptions. We are
now able to align them to the other options.
We changed include/c.h. The rest of this patch was
generated by sed, plus manually setting the right
alignment numbers. We do not change anything but
white spaces in the --help output.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This patch is trivial and changes nothing, because
we were always using usage(stdout)
Now all our usage() functions look very similar. If wanted we
could auto-generate another big cosmetical patch to remove all
the useless "FILE *out" constants and use printf and puts
rather than their f* friends. Such patch could be automatically
synchronized with the translation project (newlines!) to not
make the translators sick.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This adds a concise description of a tool to its usage text.
A first form of this patch was proposed by Steven Honeyman
(see http://www.spinics.net/lists/util-linux-ng/msg09994.html).
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
The getgroups() can return up to NGROUPS_MAX supplementary groups, that
is (since kernel 2.6.3) 65536 in total. The git_t is 4 bytes, so maximum
request is 256 kilobytes. When a system happen to have memory preasure
alloca() may not be able to allocate enough memory, making debugging
unnecessarily difficult. IMHO 64 pages is significant enough amount of
memory to be properly error checked at a time of allocation.
Reference: http://www.gnu.org/software/libc/manual/html_node/Disadvantages-of-Alloca.html
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This commit:
commit 05cef8eafb
Author: Sami Kerola <kerolasa@iki.fi>
Date: Sat Apr 13 20:54:59 2013 +0100
setpriv: check writing to a file descriptor was successful
broke --selinux-label. It checks whether fsyncing /proc/self/attr/exec
succeeds, and it doesn't, because fsync isn't supported on that file.
I have stealthily improved the error message as part of this fix.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
There were two bugs. First, trying to access /proc/self/attr/exec
with O_CREAT | O_EXCL has no chance of working. Second, it turns
out that the correct command to send is "exec", not "changeprofile".
Of course, there was no way to know this until:
commit 3eea57c26e49a5add4c053a031cc2a1977b7c48e
Author: John Johansen <john.johansen@canonical.com>
Date: Wed Feb 27 03:44:40 2013 -0800
apparmor: fix setprocattr arg processing for onexec
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Let's keep usage() simple and details in the man page. The current
brief description in usage() seems confusing for some users.
Signed-off-by: Karel Zak <kzak@redhat.com>
This new command can set no_new_privs, uid, gid, groups, securebits,
inheritable caps, the cap bounding set, securebits, and selinux and
apparmor labels.
[kerolasa@iki.fi: a lot of small adjustment making the command to be good
fit to util-linux project]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Patrick Steinhardt
Karel Zak
Ruediger Meier
Sebastian Schrader
Sami Kerola
Benno Schulenberg
Andy Lutomirski
Yuri Chornoivan