On Wed, May 02, 2012 at 10:58:57AM +0100, Pádraig Brady wrote: > On 05/02/2012 10:37 AM, Dmitry V. Levin wrote: > > On Tue, May 01, 2012 at 09:32:20PM +0100, John Lane wrote: > >> Hello, this is my first post here, I hope this is the right place to ask > >> this question. I have also asked this on Stack Exchange but I think this > >> might be a more appropriate audience. I hope that's ok. I'm experencing > >> a problem with chroot and I am running on Arch Linux x86_64. > >> > >> I have a 64 bit chroot and a 32 bit chroot. They are identical except > >> that one is 32 bit and one is 64 bit. > >> > >> I can enter either of them using "chroot /path/to/chroot". No problems. > >> > >> If I want to do that as a specific user the command is "chroot > >> --userspec=user:group /path/to/chroot" > >> > >> This also works fine for the 64 bit chroot. However it fails for the 32 > >> bit chroot. It fails with status 125 and the message "chroot: invalid user" > > > > Looks like your 64-bit glibc failed to load 32-bit NSS plugins. > > Please try this tentative patch: [...] > > Thanks for looking at this Dmitry. > > Note this very related issue/patch here: > > http://lists.gnu.org/archive/html/coreutils/2011-07/msg00057.html > > It might be best Dmitry to call parse_user_spec twice as you do, > but fall back to the initial uid, gid if the latter fails?
The more I look at this groups/userspec feature, the less I like it, because it gives false sense of security. One might wrongly assume that a command like "chroot --userspec=nobody:nobody --groups=nobody NEWROOT" will not execute arbitrary code as root outside NEWROOT, but, unfortunately, this is not the case. Not only NEWROOT/etc/passwd may define "nobody" as a user with uid==0, but a malicious NEWROOT/lib/libnss_files.so.2 may result to instant arbitrary code execution outside NEWROOT. The only secure use of groups/userspec now seems to be disabled lookup, e.g. --userspec=+99:+99 --groups=+99. From this point of view, I'd suggest to make the proposed "before" semantics a default groups/userspec behaviour as more secure, add an option to enable currently implemented "after" semantics, and document why "after" semantics is not secure with untrusted chroots. -- ldv
pgpJ5g8HB28Dh.pgp
Description: PGP signature
