netdev - Re: [PATCHv3 0/2] capability controlled user-namespaces

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: <CAF2d9jjws=jEbybHs18J_xkduAWB+bh6BA_CkD5oYRWz7PwjZA@mail.gmail.com>
Date:   Mon, 8 Jan 2018 10:55:56 -0800
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     James Morris <james.l.morris@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Kernel-hardening <kernel-hardening@...ts.openwall.com>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>,
        Mahesh Bandewar <mahesh@...dewar.net>
Subject: Re: [PATCHv3 0/2] capability controlled user-namespaces

On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com):
>> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
>> > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com):
>> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
>> >> > Quoting James Morris (james.l.morris@...cle.com):
>> >> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>> >> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
>> >> >> unnecessary jargon from an end user point of view.
>> >> >
>> >> > Ah, yes, that was my point in
>> >> >
>> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
>> >> > and
>> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
>> >> >
>> >> >> This may happen internally but don't make it a special case with a
>> >> >> different name and don't bother users with internal concepts: simply
>> >> >> implement capability whitelists with the default having equivalent
>> >
>> > So the challenge is to have unprivileged users be contained, while
>> > allowing trusted workloads in containers created by a root user to
>> > bypass the restriction.
>> >
>> > Now, the current proposal actually doesn't support a root user starting
>> > an application that it doesn't quite trust in such a way that it *is*
>> > subject to the whitelist.
>>
>> Well, this is not hard since root process can spawn another process
>> and loose privileges before creating user-ns to be controlled by the
>> whitelist.
>
> It would have to drop cap_sys_admin for the container to be marked as
> "controlled", which may prevent the container runtime from properly starting
> the container.
>
Yes, but that's a conflict of trusted operations (that requires
SYS_ADMIN) and untrusted processes it may spawn.

>> You need an ability to preserve the creation of user-namespaces that
>> exhibit 'the uncontrolled behavior' and only trusted/privileged (root)
>> user should have it which is maintained here.
>>
>> > Which is unfortunate.  But apart from using
>> > ptags or a cgroup, I can't think of a good way to get us everything we
>> > want:
>> >
>> > 1. unprivileged users always restricted
>> > 2. existing unprivileged containers become restricted when whitelist
>> > is enabled
>> > 3. privileged users are able to create containers which are not restricted
>>
>> all this is achieved by the patch-set without any changes to the
>> application with the above knob.
>>
>> > 4. privileged users are able to create containers which *are* restricted
>> >
>> With this patch-set; the root user process can fork another process
>> with less privileges before creating a user-ns if the exec-ed process
>> cannot be trusted. So there is a way with little modification as
>> opposed to nothing available at this moment for this scenario.