kern: fix setgroups(2) and getgroups(2) to match other platforms

On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only tou

kern: fix setgroups(2) and getgroups(2) to match other platforms

On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only touching the
supplementary groups of the process. This poses both portability and
security concerns in porting software to and from FreeBSD, as this
subtle difference is a landmine waiting to happen. Bugs have been
discovered even in FreeBSD-local sources, since this behavior is
somewhat unintuitive (see, e.g., fix 48fd05999b0f for chroot(8)).

Now that the egid is tracked outside of cr_groups in our ucred, convert
the syscalls to deal with only supplementary groups. Some remaining
stragglers in base that had baked in assumptions about these syscalls
are fixed in the process to avoid heartburn in conversion.

For relnotes: application developers should audit their use of both
setgroups(2) and getgroups(2) for signs that they had assumed the
previous FreeBSD behavior of using the first element for the egid. Any
calls to setgroups() to clear groups that used a single array of the
now or soon-to-be egid can be converted to setgroups(0, NULL) calls to
clear the supplementary groups entirely on all FreeBSD versions.

Co-authored-by: olce (but bugs are likely mine)
Relnotes: yes (see last paragraph)
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D51648

show more ...

chroot: don't setgroups() without -G having been specified

We previously would not have setgroups() at all, but now we would drop
our supplementary groups every time. This broke chroot -n, probably

chroot: don't setgroups() without -G having been specified

We previously would not have setgroups() at all, but now we would drop
our supplementary groups every time. This broke chroot -n, probably
among other things. We need tests here, but lets unbreak things first.

A future change may try to setgroups(2) when -u is specified in addition
to -G, so predicate the call on gidlist and don't populate that without
a grouplist.

PR: 288751
Fixes: 48fd05999b0f ("chroot: don't clobber the egid [...]")

show more ...

chroot: Remove always-true checks

gid_t and uid_t are unsigned types, so the values are always >= 0.

usr.sbin/chroot/chroot.c: In function 'resolve_group':
usr.sbin/chroot/chroot.c:68:55: error: co

chroot: Remove always-true checks

gid_t and uid_t are unsigned types, so the values are always >= 0.

usr.sbin/chroot/chroot.c: In function 'resolve_group':
usr.sbin/chroot/chroot.c:68:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
68 | if (errno == 0 && *endp == '\0' && (gid_t)gid >= 0 && gid <= GID_MAX)
| ^~
usr.sbin/chroot/chroot.c: In function 'resolve_user':
usr.sbin/chroot/chroot.c:87:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
87 | if (errno == 0 && *endp == '\0' && (uid_t)uid >= 0 && uid <= UID_MAX)
| ^~

Reported by: GCC
Fixes: 91eb4d2ba4de ("chroot: slightly cleanup")

show more ...

chroot: slightly cleanup

Highlights:
- Pull resolve_user() and resolve_group() out to make the main flow
a bit easier to read
- Fix some edge-cases in user/group resolution: you can have fully

chroot: slightly cleanup

Highlights:
- Pull resolve_user() and resolve_group() out to make the main flow
a bit easier to read
- Fix some edge-cases in user/group resolution: you can have fully
numeric usernames, and they may or may not live within the valid
ID range. Switch to just trying to resolve every specified
group/user as a name, first, with a fallback to converting it to a
numeric type and trying to resolve it as an ID.
- Constify locals in main() that don't need to be mutable, re-sort

Reviewed by: emaste, olce
Differential Revision: https://reviews.freebsd.org/D51509

show more ...

chroot: Improve error message for unprivileged use

When the security.bsd.unprivileged_chroot sysctl is set, chroot(2) can
be used by unprivileged users as long as the PROC_NO_NEW_PRIVS_CTL
process c

chroot: Improve error message for unprivileged use

When the security.bsd.unprivileged_chroot sysctl is set, chroot(2) can
be used by unprivileged users as long as the PROC_NO_NEW_PRIVS_CTL
process control is set.

chroot(8) has a -n command line flag to set this process control.
Add an explicit error for EPERM from chroot(2) if the -n flag is
necessary, but not present.

Before:
$ chroot / /bin/sh
chroot: /: Operation not permitted

After:
$ chroot / /bin/sh
chroot: unprivileged use requires -n

Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51687

show more ...

chroot: don't clobber the egid with the first supplemental group

There are two problems here, really:

1.) If -G is specified, the egid of the runner will get clobbered by
the first supplemental

chroot: don't clobber the egid with the first supplemental group

There are two problems here, really:

1.) If -G is specified, the egid of the runner will get clobbered by
the first supplemental group
2.) If both -G and -g are specified, the first supplemental group will
get clobbered by the -g group

Ideally our users shouldn't have to understand the quirks of our
setgroups(2) and the manpage doesn't describe the group list as needing
to contain the egid, so populate the egid slot as necessary.

I note that this code seems to have already been marginally aware of the
historical behavior because it was allocating NGROUPS_MAX + 1, but this
is an artifact of a later conversion to doing dynamic allocations
instead of pushing NGROUPS_MAX arrays on the stack -- the original code
did in-fact only have an NGROUPS_MAX-sized array, and the layout was
still incorrect.

MFC after: 3 days
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D51508

show more ...

Remove copyright strings ifdef'd out

We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals.

Remove copyright strings ifdef'd out

We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals. These copyright strings are present in the comments and
are largely from CSRG's attempt at adding their copyright to every
binary file (which modern interpretations of the license doesn't
require).

Sponsored by: Netflix

show more ...

usr.sbin: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a p

usr.sbin: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Mark usage function as __dead2 in programs where it does not return

In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dea

Mark usage function as __dead2 in programs where it does not return

In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735

show more ...

chroot: fix typo in usage

While here also fix typo in a variable name.

Reported By: oshogbo

Implement unprivileged chroot

This builds on recently introduced NO_NEW_PRIVS flag to implement
unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`.
It allows non-root processes to ch

Implement unprivileged chroot

This builds on recently introduced NO_NEW_PRIVS flag to implement
unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`.
It allows non-root processes to chroot(2), provided they have the
NO_NEW_PRIVS flag set.

The chroot(8) utility gets a new flag, -n, which sets NO_NEW_PRIVS
before chrooting.

Reviewed By: kib
Sponsored By: EPSRC
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D30130

show more ...

kern: fix setgroups(2) and getgroups(2) to match other platforms

On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only tou

kern: fix setgroups(2) and getgroups(2) to match other platforms

On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only touching the
supplementary groups of the process. This poses both portability and
security concerns in porting software to and from FreeBSD, as this
subtle difference is a landmine waiting to happen. Bugs have been
discovered even in FreeBSD-local sources, since this behavior is
somewhat unintuitive (see, e.g., fix 48fd05999b0f for chroot(8)).

Now that the egid is tracked outside of cr_groups in our ucred, convert
the syscalls to deal with only supplementary groups. Some remaining
stragglers in base that had baked in assumptions about these syscalls
are fixed in the process to avoid heartburn in conversion.

For relnotes: application developers should audit their use of both
setgroups(2) and getgroups(2) for signs that they had assumed the
previous FreeBSD behavior of using the first element for the egid. Any
calls to setgroups() to clear groups that used a single array of the
now or soon-to-be egid can be converted to setgroups(0, NULL) calls to
clear the supplementary groups entirely on all FreeBSD versions.

Co-authored-by: olce (but bugs are likely mine)
Relnotes: yes (see last paragraph)
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D51648

show more ...

chroot: don't setgroups() without -G having been specified

We previously would not have setgroups() at all, but now we would drop
our supplementary groups every time. This broke chroot -n, probably

chroot: don't setgroups() without -G having been specified

We previously would not have setgroups() at all, but now we would drop
our supplementary groups every time. This broke chroot -n, probably
among other things. We need tests here, but lets unbreak things first.

A future change may try to setgroups(2) when -u is specified in addition
to -G, so predicate the call on gidlist and don't populate that without
a grouplist.

PR: 288751
Fixes: 48fd05999b0f ("chroot: don't clobber the egid [...]")

show more ...

chroot: Remove always-true checks

gid_t and uid_t are unsigned types, so the values are always >= 0.

usr.sbin/chroot/chroot.c: In function 'resolve_group':
usr.sbin/chroot/chroot.c:68:55: error: co

chroot: Remove always-true checks

gid_t and uid_t are unsigned types, so the values are always >= 0.

usr.sbin/chroot/chroot.c: In function 'resolve_group':
usr.sbin/chroot/chroot.c:68:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
68 | if (errno == 0 && *endp == '\0' && (gid_t)gid >= 0 && gid <= GID_MAX)
| ^~
usr.sbin/chroot/chroot.c: In function 'resolve_user':
usr.sbin/chroot/chroot.c:87:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
87 | if (errno == 0 && *endp == '\0' && (uid_t)uid >= 0 && uid <= UID_MAX)
| ^~

Reported by: GCC
Fixes: 91eb4d2ba4de ("chroot: slightly cleanup")

show more ...

chroot: slightly cleanup

Highlights:
- Pull resolve_user() and resolve_group() out to make the main flow
a bit easier to read
- Fix some edge-cases in user/group resolution: you can have fully

chroot: slightly cleanup

Highlights:
- Pull resolve_user() and resolve_group() out to make the main flow
a bit easier to read
- Fix some edge-cases in user/group resolution: you can have fully
numeric usernames, and they may or may not live within the valid
ID range. Switch to just trying to resolve every specified
group/user as a name, first, with a fallback to converting it to a
numeric type and trying to resolve it as an ID.
- Constify locals in main() that don't need to be mutable, re-sort

Reviewed by: emaste, olce
Differential Revision: https://reviews.freebsd.org/D51509

show more ...

chroot: Improve error message for unprivileged use

When the security.bsd.unprivileged_chroot sysctl is set, chroot(2) can
be used by unprivileged users as long as the PROC_NO_NEW_PRIVS_CTL
process c

chroot: Improve error message for unprivileged use

When the security.bsd.unprivileged_chroot sysctl is set, chroot(2) can
be used by unprivileged users as long as the PROC_NO_NEW_PRIVS_CTL
process control is set.

chroot(8) has a -n command line flag to set this process control.
Add an explicit error for EPERM from chroot(2) if the -n flag is
necessary, but not present.

Before:
$ chroot / /bin/sh
chroot: /: Operation not permitted

After:
$ chroot / /bin/sh
chroot: unprivileged use requires -n

Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51687

show more ...

chroot: don't clobber the egid with the first supplemental group

There are two problems here, really:

1.) If -G is specified, the egid of the runner will get clobbered by
the first supplemental

chroot: don't clobber the egid with the first supplemental group

There are two problems here, really:

1.) If -G is specified, the egid of the runner will get clobbered by
the first supplemental group
2.) If both -G and -g are specified, the first supplemental group will
get clobbered by the -g group

Ideally our users shouldn't have to understand the quirks of our
setgroups(2) and the manpage doesn't describe the group list as needing
to contain the egid, so populate the egid slot as necessary.

I note that this code seems to have already been marginally aware of the
historical behavior because it was allocating NGROUPS_MAX + 1, but this
is an artifact of a later conversion to doing dynamic allocations
instead of pushing NGROUPS_MAX arrays on the stack -- the original code
did in-fact only have an NGROUPS_MAX-sized array, and the layout was
still incorrect.

MFC after: 3 days
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D51508

show more ...

Remove copyright strings ifdef'd out

We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals.

Remove copyright strings ifdef'd out

We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals. These copyright strings are present in the comments and
are largely from CSRG's attempt at adding their copyright to every
binary file (which modern interpretations of the license doesn't
require).

Sponsored by: Netflix

show more ...

usr.sbin: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a p

usr.sbin: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Mark usage function as __dead2 in programs where it does not return

In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dea

Mark usage function as __dead2 in programs where it does not return

In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735

show more ...

chroot: fix typo in usage

While here also fix typo in a variable name.

Reported By: oshogbo

Implement unprivileged chroot

This builds on recently introduced NO_NEW_PRIVS flag to implement
unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`.
It allows non-root processes to ch

Implement unprivileged chroot

This builds on recently introduced NO_NEW_PRIVS flag to implement
unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`.
It allows non-root processes to chroot(2), provided they have the
NO_NEW_PRIVS flag set.

The chroot(8) utility gets a new flag, -n, which sets NO_NEW_PRIVS
before chrooting.

Reviewed By: kib
Sponsored By: EPSRC
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D30130

show more ...

Merge ^/head r325999 through r326131.