Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Oct 2020 21:11:05 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Kyle Evans <kevans@freebsd.org>
Cc:        Yuri <yuri@rawbw.com>, Freebsd hackers list <freebsd-hackers@freebsd.org>
Subject:   Re: Is it possible to exit the chroot(2) environment?
Message-ID:  <20201007191105.GA15802@stack.nl>
In-Reply-To: <CACNAnaFqtpDkd76Z3vAUMcCMwTpMyfy91NPyufeVd%2B8UAqZHKQ@mail.gmail.com>
References:  <b6412618-02ec-1dbd-f474-b4412d7b774b@rawbw.com> <CANCZdfqJ14-Cpvi9%2Bd%2BHRgWbHk7vDUNNOKLUVOC9iBUqZKX=Pw@mail.gmail.com> <CACNAnaFVg2yZnWbfC=MmPfQ==XZYssHFuz%2BCjz%2B67TkZ108qRA@mail.gmail.com> <CACNAnaF-psLeTzwk=HygP4ESEynRyR-m62T1FAjw=ON6J2PVTg@mail.gmail.com> <a488f94a-6efc-27f3-d0a4-489f6f99772d@rawbw.com> <CACNAnaG_u1aVRJpKeb9n0rK4UqRRZDGBt7i=iRtPf-7kxqYQBw@mail.gmail.com> <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> <CACNAnaFqtpDkd76Z3vAUMcCMwTpMyfy91NPyufeVd%2B8UAqZHKQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 27, 2020 at 03:09:28PM -0500, Kyle Evans wrote:
> On Sun, Sep 27, 2020 at 3:04 PM Yuri <yuri@rawbw.com> wrote:

> > On 2020-09-27 12:56, Kyle Evans wrote:
> > > kern.chroot_allow_open_directories to some value that isn't 0 or 1.

> > It succeeds with kern.chroot_allow_open_directories=2.

> Ok, so Warner's proposal was correct and we've verified the semantics
> work out the same, this is simply a behavioral difference in that
> we're a little more strict -- presumably to make it less trivial to
> break out of a chroot.

> I suspect a default change for the sysctl/behavior is unlikely, your
> best bet to move forward is probably to work out if they really need
> to have dangling directories open and correct that if at all possible.

The kern.chroot_allow_open_directories sysctl is only a small speed bump
that mainly prevents accidental leaks of directory file descriptors,
since exchanging directory file descriptors via Unix domain sockets is
not prevented. That way, only the values 0 and 2 for the sysctl seem to
make sense.

Therefore, a workaround might be to stuff the file descriptor into a
Unix domain socket and close it.

If people actually build software that uses that workaround, changing
the default for the sysctl may be appropriate.

This kind of thing might help two collaborating chrooted processes
escape if there is a common directory (via nullfs or bind mounts) that
at least one of them can write to.

FreeBSD also maintains pwd_jdir for the first chroot ever done by a
process; therefore, chrooting and escaping again will not leave the
process's state unchanged, unless the process is already chrooted via,
for example, init_chroot or a jail.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201007191105.GA15802>