netdev - Re: RFC(v2): Audit Kernel Container IDs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <8760bkxn4y.fsf@xmission.com>
Date:   Thu, 12 Oct 2017 12:59:57 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     cgroups@...r.kernel.org,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Linux API <linux-api@...r.kernel.org>,
        Linux Audit <linux-audit@...hat.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux Network Development <netdev@...r.kernel.org>,
        Simo Sorce <simo@...hat.com>,
        Carlos O'Donell <carlos@...hat.com>,
        Aristeu Rozanski <arozansk@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Eric Paris <eparis@...isplace.org>, jlayton@...hat.com,
        Andy Lutomirski <luto@...nel.org>, mszeredi@...hat.com,
        Paul Moore <pmoore@...hat.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Steve Grubb <sgrubb@...hat.com>, trondmy@...marydata.com,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: RFC(v2): Audit Kernel Container IDs

Richard Guy Briggs <rgb@...hat.com> writes:

> A namespace cannot directly migrate from one container to another but
> could be assigned to a newly spawned container.  A namespace can be
> moved from one container to another indirectly by having that namespace
> used in a second process in another container and then ending all the
> processes in the first container.

Ugh no.  The semantics here are way too mushy.  We need a clean crisp
unambiguous definition or it will be impossible to get this correct and
impossible to use for any security purpose.

I understand the challenge.  Some of the container managers share
namespaces between containers.  Leading to things that are not really
contained.

Please make this concept like an indellibale die.  Once you are stained
with it you can not escape.  If you don't meet all of the criteria you
aren't stained.

The justification that I heard, and that seems legitimate is that it is
not timely and it is hard to make the connection between the distinct
unshare, setns, and clone events and what is happening in the kernel.

With that justification definitely the network namespace needs to be
stained if it is appropriate.

I also don't see why this can't be a special dedicated audit message.
I just looked at the code in the kernel and nlmsg_type is a u16.  There
are only a handful of audit message types defined.  There is absolutely
no reason to bring proc into this.

I have the same reservation as the others about defining a new cap for
this.  It should be enough to make setting the container id a one time
thing for a set of processes and namespaces.

If this is going to be security it needs to be very simple and very well defined.

Eric