From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from thejh.net ([37.221.195.125]:60060 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752402AbcADBjN (ORCPT ); Sun, 3 Jan 2016 20:39:13 -0500 Date: Mon, 4 Jan 2016 02:39:10 +0100 From: Jann Horn To: Richard Weinberger Cc: Alexander Viro , linux-fsdevel Subject: Re: [PATCH] fs: allow unprivileged chroot() Message-ID: <20160104013910.GA4991@pc.thejh.net> References: <1451721133-11722-1-git-send-email-jann@thejh.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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() >=20 > 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. Yes, on a normal vanilla kernel with a standard config, that works with just a new user namespace. 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). 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. As far as I can tell, unprivileged chroot() would expose far less new attack surface than full unprivileged namespaces support and would still be usable for lightweight linux-in-linux stuff (similar to fakechroot, although it wouldn't allow you to keep procfs, so maybe it wouldn't be sooo useful for that) and, more importantly IMO, it would allow adding sandboxing to programs that, while not perfect, "just works" across distros if the kernel is new enough, doesn't change uid mappings, is mostly reliable when used together with seccomp (apart from the case where folders are moved out of the chroot) and doesn't require the use of special APIs everywhere. (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 =66rom 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.) --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWic0+AAoJED4KNFJOeCOowM0P/iPzeTY+pTgPmaUJFwUbrS9s uRhkm3hXYUOkH4BYMAwS54JgoH3SzikvfAP6/FpKR3ycd25YhfMk3Uz5CBwFAkXB VG9ED+vCLWa0BeVHxnVWcCETxv2aZEN9L+J+Gi/LHZ9bjnr2v4SUm9V+UYvCJvSq zmZX3jX9ZeGY/Hbc21QXT58Y4Lddl/0rrrHndJ6JWuwE7JEmoEY1RQ0q9E9GYf6U LL+tCzB1ZsJ87ggqG/IkreHBL9blMwkvNAHU5fNI+24uLNxqW8/gkPcF7rH+kcZ1 SNw7Osa2Fpx4EDD/DZ/1Sar18MP2LtLtlCGC9nnWdL+yBsdwurUmG/1CxB/MbIGe rVdQN/OnT9M0XAp+EyiuDBjlwmrEeEUdYgvMlPvSn2Wu5pb457RgH2ahxOYoh7hP oJ90oiz8GYTC7nt9Nk1bUHU1m4Q5UiKrSwA4+Kz9y/y0B57IcQ0v1SMDIzDODHpB wZbLW4IhrI7EUyzBYpbGW5y18zXfce5odeDdbZEa2BBdOLpN3+DxkBCnVClwlwFg x+HlGitnQ3ao14CF8mGPZC9Aa2TJOWQLe84pUapodTHVfLAAY4T6qtlyqAd3Oz7s 4bdE2yHfDnQN7uEeXbNXL+L9TeGTqGpVeStsGqQkzDBHiUmuq3NA3rJw81dwQbFk ASTwY/90sWIZfIPIfEGC =Ugin -----END PGP SIGNATURE----- --liOOAslEiF7prFVr--