On 05/02/2012 12:08 PM, Dmitry V. Levin wrote: > 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.
I don't think there is anything secure implied, as there is nothing secure about a chroot really. I see your point, but I'm still inclined to give precedence to lookups within the chroot. cheers, Pádraig.
