From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from thejh.net ([37.221.195.125]:60101 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751894AbcADByJ (ORCPT ); Sun, 3 Jan 2016 20:54:09 -0500 Date: Mon, 4 Jan 2016 02:54:05 +0100 From: Jann Horn To: Richard Weinberger Cc: Alexander Viro , linux-fsdevel Subject: Re: [PATCH] fs: allow unprivileged chroot() Message-ID: <20160104015405.GA18808@pc.thejh.net> References: <1451721133-11722-1-git-send-email-jann@thejh.net> <20160104013910.GA4991@pc.thejh.net> <5689D029.6040901@nod.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <5689D029.6040901@nod.at> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 04, 2016 at 02:51:37AM +0100, Richard Weinberger wrote: > Am 04.01.2016 um 02:39 schrieb Jann Horn: > > On Sun, Jan 03, 2016 at 12:09:36PM +0100, Richard Weinberger wrote: > >> On Sat, Jan 2, 2016 at 8:52 AM, Jann Horn wrote: > >>> Allow unprivileged processes to chroot() themselves, under the > >>> following conditions: > >>> > >>> - The caller must have set NO_NEW_PRIVS to prevent him from > >>> invoking setuid/setgid/setcap executables in the chroot that > >>> could be tricked into opening files from the chroot. > >>> - The fs_struct must not be shared to prevent the caller from > >>> chrooting another process that does not have NO_NEW_PRIVS > >>> active. > >>> - chroot() is sometimes (mis-)used for sandboxing purposes. > >>> To prevent a simple chroot breakout using e.g. the > >>> double-chroot trick (chdir("/"), chroot("/foo"), > >>> chroot("../../../../../../../../")), require the process to > >>> be un-chrooted before performing chroot() > >> > >> What is the use case? > >> If you want to jail yourself as non-root you can create a new user and > >> mount namespace. > >> Then you're allowed to change root. > >=20 > > Yes, on a normal vanilla kernel with a standard config, that works > > with just a new user namespace. > >=20 > > There are a lot of systems with kernels that require caps for > > CLONE_NEWUSER by default because of distro patches (e.g. Debian > > and grsecurity) or that disable namespaces entirely (e.g. Android). >=20 > Well, let us focus on vanilla kernels. Okay. Yeah, true, it's not so useful on vanilla kernels. > > AFAIK Debian and grsecurity do it because from a security > > perspective, unprivileged namespaces are pretty scary and likely > > to still contain a bunch of unfixed issues. >=20 > FUD It's not. :D > > (Maybe I should send another patch for a user namespace flag > > that causes the namespace to have its parent's uid mappings from > > the perspective of processes inside it, but its real uid mappings > > from the kernel's perspective? That would, on vanilla kernels, > > at least allow unprivileged fileserver processes or so to sandbox > > themselves using user+mount namespaces without losing the ability > > to identify file owners and groups.) >=20 > Sounds promising. :-) I'll try that tomorrow. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWidC9AAoJED4KNFJOeCOooBwQAJ0k1kVlljZD+V4vUjVsj26j aUqeIzSUDvMJ9/WpRLDolFtVoa4AJb1M0FAQeTMqKwa2L4pyco2FOhiKg1s9YmUP 5TfH74w7nTqOPcw62OhtmBGm9Qah0521OJbQzaHQ62QcLTXTXoDSD91iF0n5pCli gbiyKvEKlVn2GFdafQIToMbccZm7Le4ZVF9nLhpOY8vLmWxSg2b9bi9c9m23quX4 P/vfcQ9rKJSDV7Ouug2gO+1b4ugfDiHan/lAGterk+/W3/Z7mFD1ZCY45B6hVm+I kW6z5O1Bny9gvGwLvks/N11gt0wZ7MQOFEyst3Cq9tfXJQXEkYsoBtGMIwk7z/SI Mvbd+W4vRa8yoSwJy74D1nhQiIwDVBENZrk5N0EwWAANQCCZlV7nBTjX+RD6M7lA KVx6Fn3KoZrCmKw5hmG2CHgmDX+wQ9RpU5X0XuyAUKEncLgdHXuTClKd7uf7WkUN CweSD7Uc5wcKwXLUeI00fwEuD9a+njRWX34cRqVemw7XGeVd8aa3p/MPP256o0Y1 w68SyW1cHSkCPF0UGcjRqiIHzR+l40/w09Fpq0D2ci6qYV2qpDjq+PMQsTboRx1Z IXyKKYu2DJEaEpRZ3v/vKZHYN0ZtXxU4raJ3pWWwxYPUa3EXY6cYsUkd/B4r7KsJ IYuEwAEM0qX18yo67yFe =jxv1 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--