From owner-freebsd-hackers@freebsd.org Wed Oct 7 19:11:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 003074361ED for ; Wed, 7 Oct 2020 19:11:17 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail04.stack.nl (blade.stack.nl [51.15.111.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.stack.nl", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C63pX0LLNz3ffN; Wed, 7 Oct 2020 19:11:15 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail04.stack.nl (Postfix) with ESMTP id 1CBE837C; Wed, 7 Oct 2020 19:11:08 +0000 (UTC) Received: from mail04.stack.nl ([127.0.0.1]) by localhost (mail04.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o4kJl2Pod_t; Wed, 7 Oct 2020 19:11:05 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.122.130]) by mail04.stack.nl (Postfix) with ESMTP id E08641F9; Wed, 7 Oct 2020 19:11:05 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id B3C4C20787; Wed, 7 Oct 2020 21:11:05 +0200 (CEST) Date: Wed, 7 Oct 2020 21:11:05 +0200 From: Jilles Tjoelker To: Kyle Evans Cc: Yuri , Freebsd hackers list Subject: Re: Is it possible to exit the chroot(2) environment? Message-ID: <20201007191105.GA15802@stack.nl> References: <9fa46833-63c2-a77f-98dd-111f6502dc74@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4C63pX0LLNz3ffN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jilles@stack.nl designates 51.15.111.152 as permitted sender) smtp.mailfrom=jilles@stack.nl X-Spamd-Result: default: False [-1.81 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jilles]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:51.15.111.152]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[stack.nl]; NEURAL_HAM_LONG(-1.04)[-1.041]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.43)[-0.426]; NEURAL_HAM_MEDIUM(-1.04)[-1.040]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:51.15.0.0/17, country:FR]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 19:11:17 -0000 On Sun, Sep 27, 2020 at 03:09:28PM -0500, Kyle Evans wrote: > On Sun, Sep 27, 2020 at 3:04 PM Yuri 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