From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Walters Subject: Re: [PATCH 4/4] Allow unprivileged chroot when safe Date: Mon, 16 Jan 2012 14:26:05 -0500 Message-ID: <1326741967.3467.8.camel@lenny> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Casey Schaufler , Linus Torvalds , Jamie Lokier , Will Drewry , linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, oleg@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com, corbet@lwn.net, alan@lxorguk To: Andy Lutomirski Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote: > Because chroot is an easy way to break out of chroot jail, CAP_SYS_ADMIN > is still required if the caller is already chrooted. This part is pretty gross. It means it won't work for stuff like containers (systemd-nspawn etc.) and furthermore I have plans that involve running OS trees inside a chroot, and this would obviously not work for that. Incidentally I ended up putting my setuid program here: http://git.gnome.org/browse/linux-user-chroot/ Now unfortunately, even if we say that a new setuid program is the way to gain these privileges, you still can't nest it, because all of these things are predicated on disabling setuid programs. But it would at least not fail initially if your process was inside a chroot. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756175Ab2APT0b (ORCPT ); Mon, 16 Jan 2012 14:26:31 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:36810 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754760Ab2APT02 (ORCPT ); Mon, 16 Jan 2012 14:26:28 -0500 X-Sasl-enc: d9gQ08wNbO1uzRe3ps10HeXqsh+CASjaFO7ulQgmZd1O 1326741987 Subject: Re: [PATCH 4/4] Allow unprivileged chroot when safe From: Colin Walters To: Andy Lutomirski Cc: Casey Schaufler , Linus Torvalds , Jamie Lokier , Will Drewry , linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, segoon@openwall.com, rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, oleg@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com, corbet@lwn.net, alan@lxorguk.ukuu.org.uk Date: Mon, 16 Jan 2012 14:26:05 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1326741967.3467.8.camel@lenny> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote: > Because chroot is an easy way to break out of chroot jail, CAP_SYS_ADMIN > is still required if the caller is already chrooted. This part is pretty gross. It means it won't work for stuff like containers (systemd-nspawn etc.) and furthermore I have plans that involve running OS trees inside a chroot, and this would obviously not work for that. Incidentally I ended up putting my setuid program here: http://git.gnome.org/browse/linux-user-chroot/ Now unfortunately, even if we say that a new setuid program is the way to gain these privileges, you still can't nest it, because all of these things are predicated on disabling setuid programs. But it would at least not fail initially if your process was inside a chroot.