From: Steve Grubb <sgrubb@redhat.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Paul Moore <pmoore@redhat.com>, Richard Guy Briggs <rgb@redhat.com>, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-audit@redhat.com, eparis@parisplace.org, arozansk@redhat.com, serge@hallyn.com, zohar@linux.vnet.ibm.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances Date: Fri, 15 May 2015 09:17:24 -0400 [thread overview] Message-ID: <2519397.QJshNan19e@x2> (raw) In-Reply-To: <87bnhmbp8e.fsf@x220.int.ebiederm.org> On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote: > Paul Moore <pmoore@redhat.com> writes: > > As Eric, and others, have stated, the container concept is a userspace > > idea, not a kernel idea; the kernel only knows, and cares about, > > namespaces. This is unlikely to change. > > > > However, as Steve points out, there is precedence for the kernel to record > > userspace tokens for the sake of audit. Personally I'm not a big fan of > > this in general, but I do recognize that it does satisfy a legitimate > > need. Think of things like auid and the sessionid as necessary evils; > > audit is already chock full of evilness I doubt one more will doom us all > > to hell. > > > > Moving forward, I'd like to see the following: > > > > * Create a container ID token (unsigned 32-bit integer?), similar to > > auid/sessionid, that is set by userspace and carried by the kernel to be > > used in audit records. I'd like to see some discussion on how we manage > > this, e.g. how do handle container ID inheritance, how do we handle > > nested containers (setting the containerid when it is already set), do we > > care if multiple different containers share the same namespace config, > > etc.? > > > > Can we all live with this? If not, please suggest some alternate ideas; > > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be > > true, but it doesn't help us solve the problem ;) > > Without stopping and defining what someone means by container I think it > is pretty much nonsense. Maybe this is what's hanging everyone up? Its easy to get lost when your view is down at the syscall level and what is happening in the kernel. Starting a container is akin to the idea of login. Not every call to setresuid is a login. It could be a setuid program starting or a daemon dropping privileges. The idea of a container is a higher level concept that starting a name space. I think comparing a login with a container is a useful analogy because both are higher level concepts but employ low level ideas. A login is a collection of chdir, setuid, setgid, allocating a tty, associating the first 3 file descriptors, setting a process group, and starting a specific executable. All these low level concepts each by itself is not special. A container is what we need auditing events around not creation of namespaces. If we want creation of namespaces, we can audit the clone/unshare/setns syscalls. The container is when a managing program such as docker, lxc, or sometimes systemd creates a special operating environment for the express purpose of running programs disassociated in some way from the parent namespaces, cgroups, and security assumptions. Its this orchestration, just as sshd orchestrates a login, that makes it different. > Should every vsftp connection get a container every? Every chrome tab? No. Also, note that not every program that grants a user session constitutes a login. > At some of the connections per second numbers I have seen we might > exhaust a 32bit number in an hour or two. Will any of that make sense > to someone reading the audit logs? I would agree if we were auditing creation of name spaces. But going back to the concept of login, these could occur at a high rate. This is a bruteforce login attack. We put countermeasures in place to prevent it. But it is possible for the session id to wrap. But in our case, things like lxc or docker don't start hundreds of these a minute. > Without considerning that container creation is an unprivileged > operation I think it is pretty much nonsense. Do I get to say I am any > container I want? That would seem to invalidate the concept of > userspace setting a container id. It would need to be a privileged operation just as setuid is. > How does any of this interact with setns? AKA entering a container? We have to audit this. For the moment, auditing the setns syscall may be enough. I'd have to look at the lifecycle of the application that's doing this to determine if we need more. > I will go as far as looking at patches. If someone comes up with > a mission statement about what they are actually trying to achieve and a > mechanism that actually achieves that, and that allows for containers to > nest we can talk about doing something like that. Auditing wouldn't impose any restrictions on this. We just need a way to observe actions within and associate them as needed to investigate violations of security policy. > But for right now I just hear proposals for things that make no sense > and can not possibly work. Not least because it will require modifying > every program that creates a container and who knows how many of them > there are. We only care about a couple programs doing the orchestration. They will need to have the right support added to them. I'm hoping the analogy of a login helps demonstrate what we are after. -Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> Cc: Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org, arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances Date: Fri, 15 May 2015 09:17:24 -0400 [thread overview] Message-ID: <2519397.QJshNan19e@x2> (raw) In-Reply-To: <87bnhmbp8e.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote: > Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes: > > As Eric, and others, have stated, the container concept is a userspace > > idea, not a kernel idea; the kernel only knows, and cares about, > > namespaces. This is unlikely to change. > > > > However, as Steve points out, there is precedence for the kernel to record > > userspace tokens for the sake of audit. Personally I'm not a big fan of > > this in general, but I do recognize that it does satisfy a legitimate > > need. Think of things like auid and the sessionid as necessary evils; > > audit is already chock full of evilness I doubt one more will doom us all > > to hell. > > > > Moving forward, I'd like to see the following: > > > > * Create a container ID token (unsigned 32-bit integer?), similar to > > auid/sessionid, that is set by userspace and carried by the kernel to be > > used in audit records. I'd like to see some discussion on how we manage > > this, e.g. how do handle container ID inheritance, how do we handle > > nested containers (setting the containerid when it is already set), do we > > care if multiple different containers share the same namespace config, > > etc.? > > > > Can we all live with this? If not, please suggest some alternate ideas; > > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be > > true, but it doesn't help us solve the problem ;) > > Without stopping and defining what someone means by container I think it > is pretty much nonsense. Maybe this is what's hanging everyone up? Its easy to get lost when your view is down at the syscall level and what is happening in the kernel. Starting a container is akin to the idea of login. Not every call to setresuid is a login. It could be a setuid program starting or a daemon dropping privileges. The idea of a container is a higher level concept that starting a name space. I think comparing a login with a container is a useful analogy because both are higher level concepts but employ low level ideas. A login is a collection of chdir, setuid, setgid, allocating a tty, associating the first 3 file descriptors, setting a process group, and starting a specific executable. All these low level concepts each by itself is not special. A container is what we need auditing events around not creation of namespaces. If we want creation of namespaces, we can audit the clone/unshare/setns syscalls. The container is when a managing program such as docker, lxc, or sometimes systemd creates a special operating environment for the express purpose of running programs disassociated in some way from the parent namespaces, cgroups, and security assumptions. Its this orchestration, just as sshd orchestrates a login, that makes it different. > Should every vsftp connection get a container every? Every chrome tab? No. Also, note that not every program that grants a user session constitutes a login. > At some of the connections per second numbers I have seen we might > exhaust a 32bit number in an hour or two. Will any of that make sense > to someone reading the audit logs? I would agree if we were auditing creation of name spaces. But going back to the concept of login, these could occur at a high rate. This is a bruteforce login attack. We put countermeasures in place to prevent it. But it is possible for the session id to wrap. But in our case, things like lxc or docker don't start hundreds of these a minute. > Without considerning that container creation is an unprivileged > operation I think it is pretty much nonsense. Do I get to say I am any > container I want? That would seem to invalidate the concept of > userspace setting a container id. It would need to be a privileged operation just as setuid is. > How does any of this interact with setns? AKA entering a container? We have to audit this. For the moment, auditing the setns syscall may be enough. I'd have to look at the lifecycle of the application that's doing this to determine if we need more. > I will go as far as looking at patches. If someone comes up with > a mission statement about what they are actually trying to achieve and a > mechanism that actually achieves that, and that allows for containers to > nest we can talk about doing something like that. Auditing wouldn't impose any restrictions on this. We just need a way to observe actions within and associate them as needed to investigate violations of security policy. > But for right now I just hear proposals for things that make no sense > and can not possibly work. Not least because it will require modifying > every program that creates a container and who knows how many of them > there are. We only care about a couple programs doing the orchestration. They will need to have the right support added to them. I'm hoping the analogy of a login helps demonstrate what we are after. -Steve
next prev parent reply other threads:[~2015-05-15 13:17 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-17 7:35 [PATCH V6 00/10] namespaces: log namespaces per task Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 08/10] fork: audit on creation of new namespace(s) Richard Guy Briggs [not found] ` <cover.1429252659.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-04-17 7:35 ` [PATCH V6 01/10] namespaces: expose ns_entries Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 02/10] proc_ns: define PROC_*_INIT_INO in terms of PROC_DYNAMIC_FIRST Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 03/10] audit: log namespace ID numbers Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 04/10] audit: initialize at subsystem time rather than device time Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 05/10] audit: log creation and deletion of namespace instances Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs [not found] ` <11270b0b1afd0a25b108915673e1e1b38dfeeafa.1429252659.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-05 14:22 ` Steve Grubb 2015-05-05 14:22 ` Steve Grubb 2015-05-05 14:31 ` Aristeu Rozanski 2015-05-05 14:31 ` Aristeu Rozanski [not found] ` <20150505143119.GA4350-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-05 14:46 ` Steve Grubb 2015-05-05 14:46 ` Steve Grubb 2015-05-05 14:56 ` Eric W. Biederman 2015-05-05 14:56 ` Eric W. Biederman [not found] ` <87pp6fhy4c.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-05-05 15:16 ` Steve Grubb 2015-05-05 15:16 ` Steve Grubb 2015-05-12 19:57 ` Richard Guy Briggs 2015-05-12 19:57 ` Richard Guy Briggs [not found] ` <20150512195759.GA9832-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-05-14 14:57 ` Steve Grubb 2015-05-14 14:57 ` Steve Grubb 2015-05-14 14:57 ` Steve Grubb 2015-05-14 15:12 ` LC Bruzenak 2015-05-14 15:42 ` Eric W. Biederman 2015-05-14 15:42 ` Eric W. Biederman [not found] ` <87iobvnp1t.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-05-14 16:21 ` Steve Grubb 2015-05-14 16:21 ` Steve Grubb 2015-05-14 16:36 ` LC Bruzenak 2015-05-15 2:03 ` Richard Guy Briggs 2015-05-15 2:03 ` Richard Guy Briggs 2015-05-15 2:03 ` Richard Guy Briggs 2015-05-14 15:42 ` Eric W. Biederman 2015-05-14 19:19 ` Paul Moore 2015-05-15 1:31 ` Eric W. Biederman 2015-05-15 1:31 ` Eric W. Biederman 2015-05-15 1:31 ` Eric W. Biederman [not found] ` <87bnhmbp8e.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-05-15 2:25 ` Richard Guy Briggs 2015-05-15 13:17 ` Steve Grubb 2015-05-15 21:01 ` Paul Moore 2015-05-15 2:25 ` Richard Guy Briggs 2015-05-15 13:17 ` Steve Grubb [this message] 2015-05-15 13:17 ` Steve Grubb 2015-05-15 14:51 ` Eric W. Biederman 2015-05-15 14:51 ` Eric W. Biederman 2015-05-15 21:01 ` Paul Moore 2015-05-15 2:32 ` Richard Guy Briggs [not found] ` <20150515023221.GC965-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-05-15 6:23 ` Andy Lutomirski 2015-05-15 6:23 ` Andy Lutomirski 2015-05-15 6:23 ` Andy Lutomirski [not found] ` <CALCETrWzM4+Vs8OVJWBcWJfbR_DRSb+e7SmUyy6CS4sHQaTkRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-15 12:38 ` Steve Grubb 2015-05-15 12:38 ` Steve Grubb 2015-05-15 13:17 ` Andy Lutomirski 2015-05-15 13:17 ` Andy Lutomirski 2015-05-15 21:05 ` Paul Moore 2015-05-15 21:05 ` Paul Moore 2015-05-16 9:46 ` Daniel J Walsh 2015-05-16 9:46 ` Daniel J Walsh 2015-05-16 12:16 ` Paul Moore 2015-05-16 14:46 ` Eric W. Biederman 2015-05-16 14:46 ` Eric W. Biederman 2015-05-16 14:46 ` Eric W. Biederman [not found] ` <87r3qgpol6.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-05-16 22:49 ` Paul Moore 2015-05-16 22:49 ` Paul Moore 2015-05-16 22:49 ` Paul Moore 2015-05-19 13:09 ` Richard Guy Briggs [not found] ` <20150519130911.GB20131-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-05-19 14:27 ` Paul Moore 2015-05-19 14:27 ` Paul Moore [not found] ` <CAHC9VhQs6pxFC3dvZic5XzuJr1xdJZyPjXdBoipwY3OOkng0ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-19 13:09 ` Richard Guy Briggs [not found] ` <CAHC9VhRKSK9=9qPF3dgALS=x1g3LinNeQvuhNV5TvQ=D7Szuag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-16 14:46 ` Eric W. Biederman [not found] ` <555711FA.50703-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-16 12:16 ` Paul Moore 2015-05-15 2:32 ` Richard Guy Briggs 2015-05-14 19:19 ` Paul Moore 2015-05-15 0:48 ` Richard Guy Briggs 2015-05-15 0:48 ` Richard Guy Briggs 2015-05-15 0:48 ` Richard Guy Briggs 2015-05-15 20:26 ` Paul Moore [not found] ` <20150515004855.GB10526-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-05-15 1:10 ` Oren Laadan 2015-05-15 2:11 ` Richard Guy Briggs 2015-05-15 2:11 ` Richard Guy Briggs [not found] ` <20150515021126.GA965-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-05-15 13:19 ` Daniel J Walsh 2015-05-15 13:19 ` Daniel J Walsh [not found] ` <CAA4jN2bgynVTwF+owtXgq06JMLQJpy_qokpD0mAguNYeDxmh1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-15 2:11 ` Richard Guy Briggs 2015-05-15 20:42 ` Paul Moore 2015-05-15 20:42 ` Paul Moore 2015-05-15 20:42 ` Paul Moore 2015-05-15 20:26 ` Paul Moore 2015-05-12 19:57 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 06/10] audit: dump namespace IDs for pid on receipt of AUDIT_NS_INFO Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs [not found] ` <cf1ed24f71743ea7f85682f26f3185202a1f8a32.1429252659.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-04-17 8:18 ` Peter Zijlstra 2015-04-17 8:18 ` Peter Zijlstra [not found] ` <20150417081843.GE23123-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2015-04-17 15:42 ` Richard Guy Briggs 2015-04-17 15:42 ` Richard Guy Briggs [not found] ` <20150417154250.GA26233-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-04-17 17:41 ` Peter Zijlstra 2015-04-17 17:41 ` Peter Zijlstra [not found] ` <20150417174131.GL23123-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2015-04-17 22:00 ` Richard Guy Briggs 2015-04-17 22:00 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 08/10] fork: audit on creation of new namespace(s) Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 09/10] audit: log on switching namespace (setns) Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-17 7:35 ` [PATCH V6 10/10] audit: emit AUDIT_NS_INFO record with AUDIT_VIRT_CONTROL record Richard Guy Briggs 2015-04-17 7:35 ` Richard Guy Briggs 2015-04-21 4:33 ` [PATCH V6 00/10] namespaces: log namespaces per task Eric W. Biederman 2015-04-21 4:33 ` Eric W. Biederman [not found] ` <87vbgqw163.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-04-23 3:07 ` Richard Guy Briggs 2015-04-23 3:07 ` Richard Guy Briggs 2015-04-23 20:44 ` Richard Guy Briggs [not found] ` <20150423204429.GA25794-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-04-24 19:36 ` Eric W. Biederman 2015-04-24 19:36 ` Eric W. Biederman [not found] ` <87bnid9v4f.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-04-28 2:05 ` Richard Guy Briggs 2015-04-28 2:05 ` Richard Guy Briggs [not found] ` <20150428020555.GB20713-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-04-28 2:16 ` Eric W. Biederman 2015-04-28 2:16 ` Eric W. Biederman 2015-05-08 14:42 ` Richard Guy Briggs [not found] ` <87zj5tgfpb.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> 2015-05-08 14:42 ` Richard Guy Briggs [not found] ` <20150423030751.GA6712-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> 2015-04-23 20:44 ` Richard Guy Briggs
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2519397.QJshNan19e@x2 \ --to=sgrubb@redhat.com \ --cc=arozansk@redhat.com \ --cc=containers@lists.linux-foundation.org \ --cc=ebiederm@xmission.com \ --cc=eparis@parisplace.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-audit@redhat.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=pmoore@redhat.com \ --cc=rgb@redhat.com \ --cc=serge@hallyn.com \ --cc=viro@zeniv.linux.org.uk \ --cc=zohar@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.