| 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
| ||
|
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/
Powered by blists - more mailing lists