Date:	Mon, 30 Jan 2012 16:13:39 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Colin Walters <walters@...bum.org>
Cc:	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	Casey Schaufler <casey@...aufler-ca.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jamie Lokier <jamie@...reable.org>, keescook@...omium.org,
	john.johansen@...onical.com, serge.hallyn@...onical.com,
	coreyb@...ux.vnet.ibm.com, pmoore@...hat.com, eparis@...hat.com,
	djm@...drot.org, segoon@...nwall.com, rostedt@...dmis.org,
	jmorris@...ei.org, scarybeasts@...il.com, avi@...hat.com,
	penberg@...helsinki.fi, viro@...iv.linux.org.uk, mingo@...e.hu,
	akpm@...ux-foundation.org, khilman@...com, borislav.petkov@....com,
	amwang@...hat.com, oleg@...hat.com, ak@...ux.intel.com,
	eric.dumazet@...il.com, gregkh@...e.de, dhowells@...hat.com,
	daniel.lezcano@...e.fr, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com, corbet@....net,
	alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH v3 4/4] Allow unprivileged chroot when safe

On Mon, Jan 30, 2012 at 3:55 PM, Colin Walters <walters@...bum.org> wrote:
> On Mon, 2012-01-30 at 15:15 -0800, Andy Lutomirski wrote:
>
>> You can accomplish the same thing *without a scary setuid binary*.
>> The use case doesn't even need a new complicated userspace tool.  You
>> would set up an initscript or some /etc/fstab entries and then:
>
> That requires administrative access to the system and custom
> configuration; if you have that, you could just as easily set up a
> wrapper script to run sudo + shell script to do whatever you want for
> example.
>
> That's the role schroot fills now - basically pre-canned scripts, but
> you don't get out of custom configuration or needing root access to set
> it up.   And as I mentioned in https://lkml.org/lkml/2011/12/9/213, it's
> not as interesting as you might think even in the model of
> "pre-configure, give out access to regular users", because if you allow
> uploading .debs, it's just an elaborate root shell.
>
> The most interesting thing to me is an entire setup that doesn't require
> administrative access, so you can do it on any server or workstation,
> and I have that with linux-user-chroot.
>
>> no_new_privs chroot /var/chroot/ubuntu_oneiric/ /bin/bash
>>
>> et voila.  (Where no_new_privs would be a really simple tool that does
>> PR_SET_NO_NEW_PRIVS and then execs its argument.)
>>
>> Maybe it's just me, but I think this is useful and I would, in fact,
>> use it in my regular workflow.
>
> workflow for what?  Building software?  Let's try to narrow down the
> problem we're solving here.

Building software.  I run Fedora and I write software and generate
binaries that need to work on Ubuntu.  So I keep an Ubuntu chroot
around.  On the occasions when I update the chroot, I have no problem
sudoing from the Fedora side (although this is suboptimal).  I
certainly don't need the NSS databases kept in sync, and I'd rather
minimize the complexity of things that run setuid root.

no_new_privs chroot /var/chroot/ubuntu /bin/bash is sufficient for my needs.

If we could have a full fakeroot-like setup supported, that would be
even better.  But that isn't likely to happen with a 44-line patch.


Like I said, the chroot patch is an example.  I think it has enough
valid usecases to more than justify its minimal complexity.  I also
think it's far less important than the core no_new_privs patch, which
enables lots of things beyond just chroot.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists