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

[Dmitry V. Levin]

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

pgpSqLJeGiRUA.pgp
Description: PGP signature