From: Richard Guy Briggs <rgb@redhat.com> To: Paul Moore <paul@paul-moore.com> Cc: containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List <linux-audit@redhat.com>, linux-fsdevel@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris <eparis@parisplace.org>, Serge Hallyn <serge@hallyn.com>, ebiederm@xmission.com, nhorman@tuxdriver.com, Dan Walsh <dwalsh@redhat.com>, mpatel@redhat.com Subject: Re: [PATCH ghak90 V7 20/21] audit: add capcontid to set contid outside init_user_ns Date: Mon, 21 Oct 2019 19:57:34 -0400 [thread overview] Message-ID: <20191021235734.mgcjotdqoe73e4ha@madcap2.tricolour.ca> (raw) In-Reply-To: <CAHC9VhRdNXsY4neJpSoNyJoAVEoiEc2oW5kSscF99tjmoQAxFA@mail.gmail.com> On 2019-10-21 17:43, Paul Moore wrote: > On Mon, Oct 21, 2019 at 5:38 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > On 2019-10-21 15:53, Paul Moore wrote: > > > On Fri, Oct 18, 2019 at 9:39 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > On 2019-09-18 21:22, Richard Guy Briggs wrote: > > > > > Provide a mechanism similar to CAP_AUDIT_CONTROL to explicitly give a > > > > > process in a non-init user namespace the capability to set audit > > > > > container identifiers. > > > > > > > > > > Use audit netlink message types AUDIT_GET_CAPCONTID 1027 and > > > > > AUDIT_SET_CAPCONTID 1028. The message format includes the data > > > > > structure: > > > > > struct audit_capcontid_status { > > > > > pid_t pid; > > > > > u32 enable; > > > > > }; > > > > > > > > Paul, can I get a review of the general idea here to see if you're ok > > > > with this way of effectively extending CAP_AUDIT_CONTROL for the sake of > > > > setting contid from beyond the init user namespace where capable() can't > > > > reach and ns_capable() is meaningless for these purposes? > > > > > > I think my previous comment about having both the procfs and netlink > > > interfaces apply here. I don't see why we need two different APIs at > > > the start; explain to me why procfs isn't sufficient. If the argument > > > is simply the desire to avoid mounting procfs in the container, how > > > many container orchestrators can function today without a valid /proc? > > > > Ok, sorry, I meant to address that question from a previous patch > > comment at the same time. > > > > It was raised by Eric Biederman that the proc filesystem interface for > > audit had its limitations and he had suggested an audit netlink > > interface made more sense. > > I'm sure you've got it handy, so I'm going to be lazy and ask: archive > pointer to Eric's comments? Just a heads-up, I'm really *not* a fan > of using the netlink interface for this, so unless Eric presents a > super compelling reason for why we shouldn't use procfs I'm inclined > to stick with /proc. It was actually a video call with Eric and Steve where that was recommended, so I can't provide you with any first-hand communication about it. I'll get more details... So, with that out of the way, could you please comment on the general idea of what was intended to be the central idea of this mechanism to be able to nest containers beyond the initial user namespace (knowing that a /proc interface is available and the audit netlink interface isn't necessary for it to work and the latter can be easily removed)? > > The intent was to switch to the audit netlink interface for contid, > > capcontid and to add the audit netlink interface for loginuid and > > sessionid while deprecating the proc interface for loginuid and > > sessionid. This was alluded to in the cover letter, but not very clear, > > I'm afraid. I have patches to remove the contid and loginuid/sessionid > > interfaces in another tree which is why I had forgotten to outline that > > plan more explicitly in the cover letter. > > paul moore - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
WARNING: multiple messages have this Message-ID (diff)
From: Richard Guy Briggs <rgb@redhat.com> To: Paul Moore <paul@paul-moore.com> Cc: containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List <linux-audit@redhat.com>, linux-fsdevel@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris <eparis@parisplace.org>, Serge Hallyn <serge@hallyn.com>, ebiederm@xmission.com, nhorman@tuxdriver.com, Dan Walsh <dwalsh@redhat.com>, mpatel@redhat.com Subject: Re: [PATCH ghak90 V7 20/21] audit: add capcontid to set contid outside init_user_ns Date: Mon, 21 Oct 2019 19:57:34 -0400 [thread overview] Message-ID: <20191021235734.mgcjotdqoe73e4ha@madcap2.tricolour.ca> (raw) In-Reply-To: <CAHC9VhRdNXsY4neJpSoNyJoAVEoiEc2oW5kSscF99tjmoQAxFA@mail.gmail.com> On 2019-10-21 17:43, Paul Moore wrote: > On Mon, Oct 21, 2019 at 5:38 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > On 2019-10-21 15:53, Paul Moore wrote: > > > On Fri, Oct 18, 2019 at 9:39 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > On 2019-09-18 21:22, Richard Guy Briggs wrote: > > > > > Provide a mechanism similar to CAP_AUDIT_CONTROL to explicitly give a > > > > > process in a non-init user namespace the capability to set audit > > > > > container identifiers. > > > > > > > > > > Use audit netlink message types AUDIT_GET_CAPCONTID 1027 and > > > > > AUDIT_SET_CAPCONTID 1028. The message format includes the data > > > > > structure: > > > > > struct audit_capcontid_status { > > > > > pid_t pid; > > > > > u32 enable; > > > > > }; > > > > > > > > Paul, can I get a review of the general idea here to see if you're ok > > > > with this way of effectively extending CAP_AUDIT_CONTROL for the sake of > > > > setting contid from beyond the init user namespace where capable() can't > > > > reach and ns_capable() is meaningless for these purposes? > > > > > > I think my previous comment about having both the procfs and netlink > > > interfaces apply here. I don't see why we need two different APIs at > > > the start; explain to me why procfs isn't sufficient. If the argument > > > is simply the desire to avoid mounting procfs in the container, how > > > many container orchestrators can function today without a valid /proc? > > > > Ok, sorry, I meant to address that question from a previous patch > > comment at the same time. > > > > It was raised by Eric Biederman that the proc filesystem interface for > > audit had its limitations and he had suggested an audit netlink > > interface made more sense. > > I'm sure you've got it handy, so I'm going to be lazy and ask: archive > pointer to Eric's comments? Just a heads-up, I'm really *not* a fan > of using the netlink interface for this, so unless Eric presents a > super compelling reason for why we shouldn't use procfs I'm inclined > to stick with /proc. It was actually a video call with Eric and Steve where that was recommended, so I can't provide you with any first-hand communication about it. I'll get more details... So, with that out of the way, could you please comment on the general idea of what was intended to be the central idea of this mechanism to be able to nest containers beyond the initial user namespace (knowing that a /proc interface is available and the audit netlink interface isn't necessary for it to work and the latter can be easily removed)? > > The intent was to switch to the audit netlink interface for contid, > > capcontid and to add the audit netlink interface for loginuid and > > sessionid while deprecating the proc interface for loginuid and > > sessionid. This was alluded to in the cover letter, but not very clear, > > I'm afraid. I have patches to remove the contid and loginuid/sessionid > > interfaces in another tree which is why I had forgotten to outline that > > plan more explicitly in the cover letter. > > paul moore - RGB
next prev parent reply other threads:[~2019-10-21 23:58 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-19 1:22 [PATCH ghak90 V7 00/21] audit: implement container identifier Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 01/21] audit: collect audit task parameters Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 02/21] audit: add container id Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 03/21] audit: read container ID of a process Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 04/21] audit: convert to contid list to check for orch/engine ownership Richard Guy Briggs 2019-09-26 14:46 ` Neil Horman 2019-10-25 20:00 ` Richard Guy Briggs 2019-10-25 20:00 ` Richard Guy Briggs 2019-10-28 12:20 ` Neil Horman 2019-10-11 0:38 ` Paul Moore 2019-10-25 21:00 ` Richard Guy Briggs 2019-11-08 18:26 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 05/21] audit: log drop of contid on exit of last task Richard Guy Briggs 2019-10-11 0:38 ` Paul Moore 2019-10-11 0:38 ` Paul Moore 2019-10-25 19:43 ` Richard Guy Briggs 2019-10-25 19:43 ` Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 06/21] audit: contid limit of 32k imposed to avoid DoS Richard Guy Briggs 2019-09-27 12:51 ` Neil Horman 2019-10-11 0:38 ` Paul Moore 2019-10-11 0:38 ` Paul Moore 2019-10-24 21:23 ` Richard Guy Briggs 2019-10-24 21:23 ` Richard Guy Briggs 2019-11-08 17:49 ` Paul Moore 2019-12-17 18:45 ` Richard Guy Briggs 2019-12-17 19:25 ` Steve Grubb 2019-12-17 19:56 ` Richard Guy Briggs 2019-12-17 19:56 ` Richard Guy Briggs 2019-10-25 20:15 ` Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 07/21] audit: log container info of syscalls Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 08/21] audit: add contid support for signalling the audit daemon Richard Guy Briggs 2019-10-11 0:39 ` Paul Moore 2019-10-11 0:39 ` Paul Moore 2019-10-25 19:20 ` Richard Guy Briggs 2019-11-08 17:41 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 09/21] audit: add support for non-syscall auxiliary records Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 10/21] audit: add containerid support for user records Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 11/21] audit: add containerid filtering Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 12/21] audit: add support for containerid to network namespaces Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-10-11 0:39 ` Paul Moore 2019-10-11 0:39 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 13/21] audit: NETFILTER_PKT: record each container ID associated with a netNS Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-10-11 0:39 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 14/21] audit: contid check descendancy and nesting Richard Guy Briggs 2019-10-11 0:40 ` Paul Moore 2019-10-11 0:40 ` Paul Moore 2019-10-24 22:08 ` Richard Guy Briggs 2019-10-24 22:08 ` Richard Guy Briggs 2019-10-30 20:32 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 15/21] sched: pull task_is_descendant into kernel/sched/core.c Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-10-11 0:40 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 16/21] audit: add support for contid set/get by netlink Richard Guy Briggs 2019-10-11 0:40 ` Paul Moore 2019-10-11 0:40 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 17/21] audit: add support for loginuid/sessionid " Richard Guy Briggs 2019-09-19 1:22 ` Richard Guy Briggs 2019-10-11 0:40 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 18/21] audit: track container nesting Richard Guy Briggs 2019-10-11 0:40 ` Paul Moore 2019-10-11 0:40 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 19/21] audit: check cont depth Richard Guy Briggs 2019-09-19 1:22 ` [PATCH ghak90 V7 20/21] audit: add capcontid to set contid outside init_user_ns Richard Guy Briggs 2019-10-19 1:39 ` Richard Guy Briggs 2019-10-19 1:39 ` Richard Guy Briggs 2019-10-21 19:53 ` Paul Moore 2019-10-21 21:38 ` Richard Guy Briggs 2019-10-21 21:38 ` Richard Guy Briggs 2019-10-21 21:43 ` Paul Moore 2019-10-21 23:57 ` Richard Guy Briggs [this message] 2019-10-21 23:57 ` Richard Guy Briggs 2019-10-22 0:31 ` Paul Moore 2019-10-22 12:13 ` Neil Horman 2019-10-22 14:04 ` Paul Moore 2019-10-22 20:06 ` Richard Guy Briggs 2019-10-22 20:06 ` Richard Guy Briggs 2019-10-22 14:27 ` Richard Guy Briggs 2019-10-22 14:27 ` Richard Guy Briggs 2019-10-22 14:34 ` Paul Moore 2019-10-24 21:00 ` Richard Guy Briggs 2019-10-30 20:27 ` Paul Moore 2019-10-30 22:03 ` Richard Guy Briggs 2019-10-30 22:03 ` Richard Guy Briggs 2019-10-31 13:59 ` Paul Moore 2019-10-31 14:50 ` Steve Grubb 2019-10-31 23:37 ` Paul Moore 2019-11-01 1:02 ` Duncan Roe 2019-11-01 15:09 ` Richard Guy Briggs 2019-11-01 15:09 ` Richard Guy Briggs 2019-11-01 15:13 ` Steve Grubb 2019-11-01 15:21 ` Richard Guy Briggs 2019-11-01 16:22 ` Paul Moore 2019-09-19 1:22 ` [PATCH ghak90 V7 21/21] audit: add proc interface for capcontid 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=20191021235734.mgcjotdqoe73e4ha@madcap2.tricolour.ca \ --to=rgb@redhat.com \ --cc=containers@lists.linux-foundation.org \ --cc=dhowells@redhat.com \ --cc=dwalsh@redhat.com \ --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=mpatel@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=netfilter-devel@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=omosnace@redhat.com \ --cc=paul@paul-moore.com \ --cc=serge@hallyn.com \ --cc=sgrubb@redhat.com \ --cc=simo@redhat.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.