linux-kernel - Re: chroot(2) and bind mounts as non-root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1323443171.6008.11.camel@lenny>
Date:	Fri, 09 Dec 2011 10:06:10 -0500
From:	Colin Walters <walters@...bum.org>
To:	John Stoffel <john@...ffel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root

On Fri, 2011-12-09 at 09:55 -0500, John Stoffel wrote:

> I can see that, but maybe you can still fix this in userspace using
> the schroot tool others have mentioned.  

No, because it requires root to edit /etc/schroot/schroot.conf.  I've
already said this.  What is not being understood?

Again, the design constraint I have is that you should be able to get a
plain regular Unix account on say some classical timesharing server (in
the cloud if you like, or your university's RHEL instance), and do the
build.

This is also advantageous even in the "building on personal laptop case"
in that there is *no* instance of a user process being in direct or
indirect control over processes started as root - much less chance one
of those random postinst scripts that run as root not noticing they're
in a chroot and screwing your system.

If you allow the a user to upload .debs to the URL in schroot.conf, all
you have created in the end is a very elaborate chmod u+s /bin/sh for
them.

Does that make sense?  Stop telling me about schroot, I knew about it
even before I posted here, and I've already replied about it.

--
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/