[Bug 121073] [kernel] [patch] run chroot as an unprivileged user

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

Eitan Adler <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsd-***@FreeBSD.org

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

Robert Watson <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

--- Comment #8 from Robert Watson <***@FreeBSD.org> ---
A appreciate the desirability for the features implied by this change, but
given the propensity for vulnerabilities relating to chroot() in the past,
think we should take a very conservative approach to potentially adopting it.
There's a particular concern with how it interacts with non-UNIX-ID-based
models -- e.g., MAC, Capsicum, Audit, Jail, as well as a future fine-grained
privilege model.

Overall, I'd rate this proposed change as "extremely high risk; we will fix
multiple vulnerabilities in it in the future," and so that cost would need to
be carefully weighed against presumed benefit -- a fine-grained privilege model
in which PRIV_CHROOT is delegable to only specific users or roles would help
mitigate that risk.

I wonder if a more suitable name for the proposed P_NOSUGID would be
P_NOCREDCHANGE, and I also wonder if it should be CR_NOCREDCHANGE.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

--- Comment #9 from Nathan Whitehorn <***@FreeBSD.org> ---
There are, I think, two potential security issues here:
1. Many pieces of software assume that if you chroot and drop privileges, no
further chroot is possible.
2. There could be sneaky ways of obtaining privileges once no-new-privileges is
set.

(1) is pretty straightforward since we can just disallow unprivileged chroot
after any other chroot. (2) is the complex one. Are there others?

Some no-cred-change property for processes seems extremely useful from a
security perspective and, if we have one we could trust, this patch becomes
trivial. Would it make sense just to work on that first and come back to
unprivileged chroot later?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

--- Comment #10 from Robert Watson <***@FreeBSD.org> ---
Just to follow up on Nathan and my conversation on IRC, things are made rather
more complicated than one might hope by a gradual increase in the number of
processes, over time, with credential changes. For example, Mac OS X's
sandboxing system, based on our MAC Framework, frequently experiences domain
transitions, and we could anticipate similar changes. It sounds like there is
a net agreement that adopting a nice model for finer-grained, role-based
privileges (e.g., the Solaris model) would have significant benefit to reducing
the exposure in the event something did go wrong with unprivileged chroot --
and solve a number of other problems (e.g., unprivileged DTrace, better
privilege-set abstractions for Jail), and is a worthy cause on the path to this
sort of change. However, unprivileged chroot() will remain a sticky problem as
programs of necessity place enormous trust in the UNIX filesystem namespace --
especially when it comes to features such as runtime linking, configuration
files, etc, so if there is any form of 'call-gate'-style privilege escalation
(e.g., setuid, setgid, TE MAC transitioning binaries), we could get ourselves
into trouble.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

Julian Elischer <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

--- Comment #12 from Julian Elischer <***@FreeBSD.org> ---
If the ability to do this operation (unpriv chroot) is inherited, and the
ability to set that bit is only settable by root then a process can only do
this if a root ancestor has said that security is being lowered by this family
of processes. I would even go as far as saying secure level would disable it
along with a "no return" policy. (by which I mean once it is set in a process
and then used you cannot get that ability back ... full stop.)

This would allow the use of the functionality for "build machine" type
situations where in reality it is root or trusted proxy doing the chroot. In
addition it should be a one-shot.. you use it , you lose it.
With the advent of "everyone has there own computer" I am not sure how
important it is to have "real users" be able to do builds.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

Eitan Adler <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|In Progress |Open

--- Comment #11 from Eitan Adler <***@FreeBSD.org> ---
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "***@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"