Re: chroot with --userspec when chrooting from x86_64 to i686

[Pádraig Brady]

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.