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
| ||
|
Message-ID: <1513009857.6310.337.camel@redhat.com> Date: Mon, 11 Dec 2017 11:30:57 -0500 From: Eric Paris <eparis@...hat.com> To: Casey Schaufler <casey@...aufler-ca.com>, Mickaël Salaün <mic@...ikod.net>, Richard Guy Briggs <rgb@...hat.com>, 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> Cc: mszeredi@...hat.com, "Eric W. Biederman" <ebiederm@...ssion.com>, Simo Sorce <simo@...hat.com>, jlayton@...hat.com, Carlos O'Donell <carlos@...hat.com>, David Howells <dhowells@...hat.com>, Al Viro <viro@...iv.linux.org.uk>, Andy Lutomirski <luto@...nel.org>, Eric Paris <eparis@...isplace.org>, trondmy@...marydata.com, Michael Kerrisk <mtk.manpages@...il.com> Subject: Re: RFC(v2): Audit Kernel Container IDs On Sat, 2017-12-09 at 10:28 -0800, Casey Schaufler wrote: > On 12/9/2017 2:20 AM, Micka�l Sala�n wrote: > > What about automatically create > > and assign an ID to a process when it enters a namespace different > > than > > one of its parent process? This delegates the (permission) > > responsibility to the use of namespaces (e.g. /proc/sys/user/max_* > > limit). > > That gets ugly when you have a container that uses user, filesystem, > network and whatever else namespaces. If all containers used the same > set of namespaces I think this would be a fine idea, but they don't. > > > One interesting side effect of this approach would be to be able to > > identify which processes are in the same set of namespaces, even if > > not > > spawn from the container but entered after its creation (i.e. using > > setns), by creating container IDs as a (deterministic) checksum > > from the > > /proc/self/ns/* IDs. > > > > Since the concern is to identify a container, I think the ability > > to > > audit the switch from one container ID to another is enough. I > > don't > > think we need nested IDs. > > Because a container doesn't have to use namespaces to be a container > you still need a mechanism for a process to declare that it is in > fact > in a container, and to identify the container. I like the idea but I'm still tossing it around in my head (and thinking about Casey's statement too). Lets say we have a 'docker-like' container with pid=100 netns=X,userns=Y,mountns=Z. If I'm on the host in all init namespaces and I run nsenter -t 100 -n ip link set eth0 promisc on How should this be logged? Did this command run in it's own 'container' unrelated to the 'docker-like' container? -Eric
Powered by blists - more mailing lists