Dave Reisner [Mon, 16 Dec 2019 19:11:23 +0000 (14:11 -0500)]
Don't auto-enable ACCT_TOOLS_SETUID if PAM is detected
Here's a sad story:
* 70971457 is merged into shadow, allowing newgidmap/newuidmap to be
installed with file caps rather than setuid.
* https://bugs.archlinux.org/task/63248 is filed to take advantage of
this.
* The arch maintainer of the 'shadow' package notices that this doesn't
work, and submits a pull request to fix this in shadow.
* edf7547ad5 is merged, fixing the post install hooks.
The problem here is that distros have been building shadow with PAM for
O(years), but the install hooks have silently failed due to the
combination of the directory mismatch (suidubins vs suidsbins) and later
success with setuid'ing newgidmap/newuidmap.
With the install hooks fixed, those of us (Arch[1] and Gentoo[2] so far)
who never built shadow explicitly with --enable-account-tools-setuid are
now getting setuid account tools, and don't have PAM configuration
suitable for use with setuid account management tools.
It's entirely unclear to me why you'd want this, but I assume there's
some reason out there for it existing. Regardless, setuid binaries are
dangerous and shouldn't be enabled by default without good reason.
See https://github.com/shadow-maint/shadow/issues/196
Some distros still care about `/bin` vs `/usr/bin`. This commit makes
it so all binaries are always installed to `/bin`/`/sbin`. The only way to
restore the previous behaviour of installing some binaries to
`/usr/bin`/`/usr/sbin` is to revert the patch.
The problem is that vipw forks a child process and calls waitpid() with the
WUNTRACED flag. When the child process (running the editor) is suspended, the
parent sends itself SIGSTOP to suspend the main vipw process. However, because
the main vipw is in the same process group as the editor which received the ^Z,
the kernel already sent the main vipw SIGTSTP.
If the main vipw receives SIGTSTP before the child, it will be suspended and
then, once resumed, will proceed to suspend itself again.
To fix this, run the child process in its own process group as the foreground
process group. That way, control-Z will only affect the child process and the
parent can use the existing logic to suspend the parent.
man: generate translations using itstool instead of xml2po
This patch was taken from Fedora Rawhide
https://src.fedoraproject.org/rpms/shadow-utils/raw/b41cff195605b29af23d2ad62a60ddc5a2d89786/f/shadow-4.6-use-itstool.patch
Using hard-coded access vector ids is deprecated and can lead to issues with custom SELinux policies.
Switch to `selinux_check_access()`.
Also use the libselinux log callback and log if available to audit.
This makes it easier for users to catch SELinux denials.
Drop legacy shortcut logic for passwd, which avoided a SELinux check if uid 0 changes a password of a user which username equals the current SELinux user identifier.
Nowadays usernames rarely match SELinux user identifiers and the benefit of skipping a SELinux check is negligible.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
With this, it is possible for Linux distributors to store their
supplied default configuration files somewhere below /usr, while
/etc only contains the changes made by the user. The new option
--enable-vendordir defines where the shadow suite should additional
look for login.defs if this file is not in /etc.
libeconf is a key/value configuration file reading library, which
handles the split of configuration files in different locations
and merges them transparently for the application.
Dave Reisner [Wed, 31 Jul 2019 17:09:36 +0000 (13:09 -0400)]
Fix failing chmod calls on installation for suidubins
suidubins should be suidusbins, since these binaries are installed
${prefix}/sbin. This historically hasn't broken the build because
chmod of newgidmap/newuidmap succeeds, causing make to think the command
succeeded. Configuring shadow with --with-fcaps removes these final two
entries and exposes the chmod failure to make.
Dave Reisner [Wed, 31 Jul 2019 17:09:36 +0000 (13:09 -0400)]
Honor --sbindir and --bindir for binary installation
Some distros don't care about the split between /bin, /sbin, /usr/bin,
and /usr/sbin, so let them easily stuff binaries wherever they want.
This also fixes a problem during installation where-in a loop of 'chmod
4755' calls will mostly fail. However, because the last two succeed
(newuidmap/newgidmap), make considers the command to be a success.
Somewhat not-amusingly, configuring shadow with --with-fcaps will cause
installation to fail because the final chmod call is now a failing one.
Stanislav Brabec [Fri, 26 Jul 2019 20:47:05 +0000 (22:47 +0200)]
login.defs: Cosmetic space change
Fix formatting of login.defs comments. Variables are preceeded by "#"
without space, comments are preceeded by "# ". It makes the file machine
parseable again.
Yi Zhao [Mon, 17 Jun 2019 07:36:34 +0000 (15:36 +0800)]
configure.ac: fix configure error with dash
A configure error occurs when /bin/sh -> dash:
checking for is_selinux_enabled in -lselinux... yes
checking for semanage_connect in -lsemanage... yes
configure: 16322: test: yesyes: unexpected operator
Use "=" instead of "==" since dash doesn't support this operator.
Adam Majer [Mon, 21 Jan 2019 08:32:36 +0000 (09:32 +0100)]
Add support for btrfs subvolumes for user homes
new switch added to useradd command, --btrfs-subvolume-home. When
specified *and* the filesystem is detected as btrfs, it will create a
subvolume for user's home instead of a plain directory. This is done via
`btrfs subvolume` command. Specifying the new switch while trying to
create home on non-btrfs will result in an error.
userdel -r will handle and remove this subvolume transparently via
`btrfs subvolume` command. Previosuly this failed as you can't rmdir a
subvolume.
usermod, when moving user's home across devices, will detect if the home
is a subvolume and issue an error messages instead of copying it. Moving
user's home (as subvolume) on same btrfs works transparently.
Tomas Mraz [Thu, 2 May 2019 12:39:01 +0000 (14:39 +0200)]
Do not fail locking if there is a stale lockfile.
As the lockfiles have PID in the name, there can be no conflict
in the name with other process, so there is no point in using
O_EXCL and it only can fail if there is a stale lockfile from
previous execution that crashed for some reason.
Tomas Mraz [Thu, 2 May 2019 12:33:06 +0000 (14:33 +0200)]
Use the lckpwdf() again if prefix is not set
The implementation of prefix option dropped the use of lckpwdf().
However that is incorrect as other tools manipulating the shadow passwords
such as PAM use lckpwdf() and do not know anything about the
shadow's own locking mechanism.
This reverts the implementation to use lckpwdf() if prefix option
is not used.
Chris Lamb [Wed, 2 Jan 2019 18:06:16 +0000 (18:06 +0000)]
Make the sp_lstchg shadow field reproducible (re. #71)
From <https://github.com/shadow-maint/shadow/pull/71>:
```
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.
```
This updated PR adds some missing calls to gettime (). This was originally
filed by Johannes Schauer in Debian as #917773 [2].
Tomas Mraz [Tue, 18 Dec 2018 15:32:13 +0000 (16:32 +0100)]
usermod: Guard against unsafe change of ownership of home directory content
In case the home directory is not a real home directory
(owned by the user) but things like / or /var or similar,
it is unsafe to change ownership of home directory content.
The test checks whether the home directory is owned by the
user him/herself, if not no ownership modification of contents
is performed.
Tomas Mraz [Wed, 28 Nov 2018 13:57:16 +0000 (14:57 +0100)]
login.defs: Add LASTLOG_UID_MAX variable to limit lastlog to small uids.
As the large uids are usually provided by remote user identity and
authentication service, which also provide user login tracking,
there is no need to create a huge sparse file for them on every local
machine.
fixup! login.defs: Add LASTLOG_UID_MAX variable to limit lastlog to small uids.
idmap: always seteuid to the owner of the namespace
simplify the condition for setting the euid of the process. Now it is
always set when we are running as root, the issue was introduced with
the commit 52c081b02c4ca4432330ee336a60f6f803431e63
Changelog: 2018-11-24 - seh - enforce that euid only gets set to ruid if
it currently == 0 (i.e. really was setuid-*root*).
Closes: https://github.com/genuinetools/img/issues/191 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Serge Hallyn <shallyn@cisco.com>
Commit 1ecca8439d5 ("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:
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.
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
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: 1ecca8439d5 ("new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS") Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
newuidmap/newgidmap: install with file capabilities
do not install newuidmap/newgidmap as suid binaries. Running these
tools with the same euid as the owner of the user namespace to
configure requires only CAP_SETUID and CAP_SETGID instead of requiring
CAP_SYS_ADMIN when it is installed as a suid binary.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
projects / thirdparty / shadow.git / log
