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

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Priority|Normal  |---
   Assignee|b...@freebsd.org|tr...@freebsd.org
 Resolution|Overcome By Events  |FIXED
URL||https://reviews.freebsd.org
   ||/D30130
Version|8.0-CURRENT |12.2-RELEASE

--- Comment #14 from Kubilay Kocak  ---
^Triage:

 - Correct resolutions (FIXED .. 'issue as reported', by commit, even if not by
patch attached here)
 - Assign to committer that resolved
 - Add meta (review)
 - Set version to earliest (currently) supported branch/version

@trasz If this ended up being MFC'd to stable/13 (was probably current at the
time?) or stable/12, please set mfc-stableX flags as appropriate

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |Overcome By Events

--- Comment #13 from Ed Maste  ---
Implemented in:

commit a40cf4175c90142442d0c6515f6c83956336699b
Author: Edward Tomasz Napierala 
Date:   Tue Jul 20 08:56:04 2021 +

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

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

Julian Elischer  changed:

   What|Removed |Added

 CC||jul...@freebsd.org

--- Comment #12 from Julian Elischer  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

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

[bugzilla-noreply]

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

Eitan Adler  changed:

   What|Removed |Added

 Status|In Progress |Open

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

Do
- Set Status to "Open"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

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

[bugzilla-noreply]

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

--- Comment #10 from Robert Watson rwat...@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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

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

[bz-noreply]

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

Robert Watson rwat...@freebsd.org changed:

   What|Removed |Added

 CC||rwat...@freebsd.org

--- Comment #8 from Robert Watson rwat...@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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

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

[bugzilla-noreply]

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

--- Comment #9 from Nathan Whitehorn nwhiteh...@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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

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

[bz-noreply]

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

Nathan Whitehorn nwhiteh...@freebsd.org changed:

   What|Removed |Added

  Attachment #84994|0   |1
is obsolete||
 CC||nwhiteh...@freebsd.org

--- Comment #6 from Nathan Whitehorn nwhiteh...@freebsd.org ---
Created attachment 143547
  -- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=143547action=edit
Prevents escape from unprivileged chroot

This fixes the issue of using this feature to escape from a chroot established
with privileges after dropping them by the simple expedient of unconditionally
preventing unprivileged chroot while already in a chroot.

The second issue raised (MAC transitions) I know nothing about and cannot
address.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

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

[bz-noreply]

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

--- Comment #7 from ji...@quis.cx ---
I remember someone saying this could be exploited using rfork. I don't know why
it's not listed in this bug.

IIRC the problem was that fd_rdir (root of the processes) was stored in
proc-p_fd (struct filedesc) and the P_NOSUGID-flag in struct proc itself. One
could use rfork to create a new process with the same descriptor table and call
chroot in the child which would flag the child with P_NOSUGID but change to
root for the parent as well. The parent doesn't get P_NOSUGID however and will
be able to execve a setuid executable with a fake libc.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org