Aleksa Sarai [Thu, 15 Feb 2018 12:49:40 +0000 (23:49 +1100)]
newgidmap: enforce setgroups=deny if self-mapping a group
This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.
This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).
We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".
Tomas Mraz [Mon, 14 Aug 2017 09:38:46 +0000 (11:38 +0200)]
newgrp: avoid unnecessary group lookups
In case a system uses remote identity server (LDAP) the group lookup
can be very slow. We avoid it when we already know the user has the
group membership.
Do not reset the pid_child to 0 if the child process is still
running. This else-condition can be reached with pid being -1,
therefore explicitly test this condition.
This is a regression fix for CVE-2017-2616. If su receives a
signal like SIGTERM, it is not propagated to the child.
Reported-by: Radu Duta <raduduta@gmail.com> Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Chris Lamb [Wed, 15 Mar 2017 10:36:21 +0000 (10:36 +0000)]
Make the sp_lstchg shadow field reproducible.
The third field in the /etc/shadow file (sp_lstchg) contains the date of
the last password change expressed as the number of days since Jan 1, 1970.
As this is a relative time, creating a user today will result in:
username:17238:0:99999:7:::
whilst creating the same user tomorrow will result in:
username:17239:0:99999:7:::
This has an impact for the Reproducible Builds[0] project where we aim to
be independent of as many elements the build environment as possible,
including the current date.
This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
environment variable (instead of Jan 1, 1970) if valid.
Tomas Mraz [Fri, 31 Mar 2017 14:25:06 +0000 (16:25 +0200)]
Fix buffer overflow if NULL line is present in db.
If ptr->line == NULL for an entry, the first cycle will exit,
but the second one will happily write past entries buffer.
We actually do not want to exit the first cycle prematurely
on ptr->line == NULL. Signed-off-by: Tomas Mraz <tmraz@fedoraproject.org>
If su is compiled with PAM support, it is possible for any local user
to send SIGKILL to other processes with root privileges. There are
only two conditions. First, the user must be able to perform su with
a successful login. This does NOT have to be the root user, even using
su with the same id is enough, e.g. "su $(whoami)". Second, SIGKILL
can only be sent to processes which were executed after the su process.
It is not possible to send SIGKILL to processes which were already
running. I consider this as a security vulnerability, because I was
able to write a proof of concept which unlocked a screen saver of
another user this way.
David Michael [Wed, 8 Feb 2017 23:48:36 +0000 (15:48 -0800)]
useradd: Read defaults after changing root directories
This reverts the behavior of "useradd --root" to using the settings
from login.defs in the target root directory, not the root of the
executed useradd command.
Tomas Mraz [Tue, 15 Nov 2016 14:43:54 +0000 (15:43 +0100)]
Make the group and user allocation more effective.
Previously, the allocation was optimized for an outdated
deployment style (that of /etc/group alongside nss_db). The issue
here is that this results in extremely poor performance when using
SSSD, Winbind or nss_ldap.
There were actually two serious bugs here that have been addressed:
1) Running getgrent() loops won't work in most SSSD or Winbind
environments, as full group enumeration is disabled by default.
This could easily result in auto-allocating a group that was
already in use. (This might result in a security issue as well, if
the shared GID is a privileged group).
2) For system groups, the loop was always iterating through the
complete SYS_GID_MIN->SYS_GID_MAX range. On SSSD and Winbind, this
means hundreds of round-trips to LDAP (unless the GIDs were
specifically configured to be ignored by the SSSD or winbindd).
To a user with a slow connection to their LDAP server, this would
appear as if groupadd -r was hung. (Though it would eventually
complete).
This patch changes the algorithm to be more favorable for LDAP
environments, at the expense of some performance when using nss_db.
Given that the DB is a local service, this should have a negligible
effect from a user's perspective.
With the new algorithm, we simply first iterate through all entries
in the local database with gr_next(), recording the IDs that are in
use. We then start from the highest presumed-available entry and
call getgrgid() to see if it is available. We continue this until
we come to the first unused GID. We then select that and return it.
If we make it through all the remaining IDs without finding a free
one, we start over from the beginning of the range and try to find
room in one of the gaps in the range.
The patch was originally written by Stephen Gallagher and applied
identically also to the user allocation by Tomáš Mráz.
projects / shadow / log