linux-kernel - Re: linux-user-chroot 2012.2

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVOcNxfiAm0QDUjqhn=yx5LTPEKBJw8To-AcOTM3d1UcQ@mail.gmail.com>
Date:	Mon, 13 Aug 2012 11:10:46 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Colin Walters <walters@...bum.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: linux-user-chroot 2012.2

On Fri, Aug 10, 2012 at 1:58 PM, Colin Walters <walters@...bum.org> wrote:
> Hi,
>
> This is the release of linux-user-chroot 2012.2.  The major change now
> is that it makes use of Andy's new PR_SET_NO_NEW_PRIVS.  This doesn't
> close any security hole I'm aware of - our previous use of the MS_NOSUID
> bind mount over / should work - but, belt and suspenders as they say.
>
> The code:
> http://git.gnome.org/browse/linux-user-chroot/commit/?id=515c714471d0b5923f6633ef44a2270b23656ee9
>
> As for how linux-user-chroot and PR_SET_NO_NEW_PRIVS relate, see this
> thread:
> http://thread.gmane.org/gmane.linux.kernel.lsm/15339
>
> Summary
> -------
>
> This tool allows regular (non-root) users to call chroot(2), create
> Linux bind mounts, and use some Linux container features.  It's
> primarily intended for use by build systems.

Nifty.

One of these days, I intend to resurrect my unprivileged chroot kernel
patches.  My current thought is to add a new syscall weak_chroot,
which should have these properties:

1. Can't be used unless no_new_privs is set or you have CAP_SYS_ADMIN.
2. Can't be used if fs->users > 1 (to avoid a trivial no_new_privs bypass).
3. Can't be used to break out of chroot jail.

The interface might be:

weak_chroot_at(int fd, const char *path, int flags)

Sets fs->weak_root to path, as seen from fd, according to flags.
Works if (no_new_privs && fs->users == 1) || capable(CAP_SYS_ADMIN).

Modify chroot to change fs->weak_root and fs->root.  Further modify
the path walking code so that / sees weak_root instead of root and so
that .. will not traverse root or weak_root.

I'm somewhat tempted to add a flag to weak_chroot_at to break out of
weak_root jail to prevent people from thinking that it's a security
feature.  I'm not sure about that, though.

--Andy
--
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/