Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jun 2014 15:04:34 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arch@FreeBSD.org
Subject:   [Bug 121073] [kernel] [patch] run chroot as an unprivileged user
Message-ID:  <bug-121073-24229-XoQa1xU0hr@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-121073-24229@https.bugs.freebsd.org/bugzilla/>
References:  <bug-121073-24229@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073

--- Comment #10 from Robert Watson <rwatson@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 on the CC list for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-121073-24229-XoQa1xU0hr>