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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Kubilay Kocak changed: What|Removed |Added Priority|Normal |---

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Ed Maste changed: What|Removed |Added Status|Open|Closed Resolution|---

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Julian Elischer changed: What|Removed |Added CC|

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Eitan Adler changed: What|Removed |Added Status|In Progress |Open ---

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

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

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Robert Watson rwat...@freebsd.org changed: What|Removed |Added CC|

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

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

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Nathan Whitehorn nwhiteh...@freebsd.org changed: What|Removed |Added Attachment #84994|0 |1

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

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