[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191021213824.6zti5ndxu7sqs772@madcap2.tricolour.ca>
Date: Mon, 21 Oct 2019 17:38:24 -0400
From: Richard Guy Briggs <rgb@...hat.com>
To: Paul Moore <paul@...l-moore.com>
Cc: containers@...ts.linux-foundation.org, linux-api@...r.kernel.org,
Linux-Audit Mailing List <linux-audit@...hat.com>,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
sgrubb@...hat.com, omosnace@...hat.com, dhowells@...hat.com,
simo@...hat.com, Eric Paris <eparis@...isplace.org>,
Serge Hallyn <serge@...lyn.com>, ebiederm@...ssion.com,
nhorman@...driver.com, Dan Walsh <dwalsh@...hat.com>,
mpatel@...hat.com
Subject: Re: [PATCH ghak90 V7 20/21] audit: add capcontid to set contid
outside init_user_ns
On 2019-10-21 15:53, Paul Moore wrote:
> On Fri, Oct 18, 2019 at 9:39 PM Richard Guy Briggs <rgb@...hat.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.
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@...hat.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
Powered by blists - more mailing lists