Date: Tue, 19 Oct 2010 21:25:57 -0700 From: Julian Elischer <julian@freebsd.org> To: Devin Teske <dteske@vicor.com> Cc: freebsd-rc@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) Message-ID: <4CBE6F55.5040609@freebsd.org> In-Reply-To: <1287540769.25599.73.camel@localhost.localdomain> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/19/10 7:12 PM, Devin Teske wrote:
> On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote:
>> On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote:
>>> I added `-j jail' for specifying a jail id or name to operate within
>>> (requires jls(8); overrides `-R dir').
>> [...]
>>
>> Note that operating on jail files from outside a jail is serious
>> security problem. The files from within the jail can be symbolic links
>> that point to files from outside a jail from your perspective. Even
>> chroot(2) to jail's root is neither safe (running applications that can
>> be modified by jail's root is obvious security hole) nor reliable (jail
>> might not have all the commands). The only safe way is to jexec(8) into
>> a jail, but it of course has the same relialability issue as chroot(8).
>>
> I see the concern, and you're absolutely right.
>
> I did see the need to use either chroot(8) or jexec(8), but for exactly
> the same reasons you mention (handing execution off-to something that
> could have been modified by the jail's root-user), I ended up writing
> routines that just edited the files outside the jail.
>
> It appears that (due to the other aforementioned security problem,
> involving hand-crafted symbolic links with malicious-intent), the only
> proper solution would be:
>
> a. Copy ourselves into some temporary location within the jail
> b. Hand execution off to ourself using either jexec(8) or chroot(8)
>
can you fire off a shell in the jail and somehow shove yourself down
it's throat?
I vaguely remember that one could feed a shell script into the shell
somehow..
but I forget the details.
> And in doing that, we'll be properly jailed so that no matter the attack
> vector, we'll be covered via the kernel's built-in protection.
>
> How does that sound?
>
> For example (note: die() is a custom shell function and it does what
> you'd expect it to):
>
> progname="${0##*/}"
> tmp="$ROOTDIR/tmp/$progname"
> case "$0" in
> */*) cp "$0" "$tmp" || die \
> "%s: Unable to copy self to \`%s'" \
> "$progname" "$tmp"
> ;;
> *) for dir in $PATH; do
> [ -f "$dir/$progname" -a -x "$dir/$progname" ] || continue
> cp "$dir/$progname" "$tmp" || die \
> "%s: Unable to copy self to \`%s'" \
> "$progname" "$tmp"
> break
> done
> [ -f "$tmp" -a -x "$tmp" ] || die \
> "%s: Unable to copy self to \`%s'" \
> "$progname" "$tmp"
> esac
> jexec $JAIL $tmp \
> ${SYSRC_VERBOSE:+-v} \
> ${RC_CONFS:+-f"$RC_CONFS"} \
> $( [ "$SHOW_ALL" = "1" ]&& echo -a ) \
> $( [ "$SHOW_ALL" = "2" ]&& echo -A ) \
> ${DESCRIBE:+-d} \
> ${SHOW_EQUALS:+-e} \
> ${IGNORE_UNKNOWNS:+-i} \
> ${SHOW_NAME:--n} \
> ${SHOW_VALUE:--N} \
> ${ROOTDIR:+-R"$ROOTDIR"}
>
> Or something like that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBE6F55.5040609>