From: ebiederm@xmission.com (Eric W. Biederman)
To: Paul Moore <paul@paul-moore.com>
Cc: Daniel J Walsh <dwalsh@redhat.com>,
Paul Moore <pmoore@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
"Serge E. Hallyn" <serge@hallyn.com>,
Richard Guy Briggs <rgb@redhat.com>,
Linux API <linux-api@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-audit@redhat.com,
Network Development <netdev@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Eric Paris <eparis@parisplace.org>
Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
Date: Sat, 16 May 2015 09:46:29 -0500 [thread overview]
Message-ID: <87r3qgpol6.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CAHC9VhRKSK9=9qPF3dgALS=x1g3LinNeQvuhNV5TvQ=D7Szuag@mail.gmail.com> (Paul Moore's message of "Sat, 16 May 2015 08:16:55 -0400")
Paul Moore <paul@paul-moore.com> writes:
> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> On 05/15/2015 05:05 PM, Paul Moore wrote:
>>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>>>>> On 15/05/14, Paul Moore wrote:
>>>>>> * Look at our existing audit records to determine which records should
>>>>>> have
>>>>>> namespace and container ID tokens added. We may only want to add the
>>>>>> additional fields in the case where the namespace/container ID tokens are
>>>>>> not the init namespace.
>>>>> If we have a record that ties a set of namespace IDs with a container
>>>>> ID, then I expect we only need to list the containerID along with auid
>>>>> and sessionID.
>>>> The problem here is that the kernel has no concept of a "container", and I
>>>> don't think it makes any sense to add one just for audit. "Container" is a
>>>> marketing term used by some userspace tools.
>>>>
>>>> I can imagine that both audit could benefit from a concept of a
>>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>>>> something along those lines). Mapping these to "containers" belongs
>>>> in userspace, I think.
>>> It might be helpful to climb up a few levels in this thread ...
>>>
>>> I think we all agree that containers are not a kernel construct. I further
>>> believe that the kernel has no business generating container IDs, those should
>>> come from userspace and will likely be different depending on how you define
>>> "container". However, what is less clear to me at this point is how the
>>> kernel should handle the setting, reporting, and general management of this
>>> container ID token.
>>>
>> Wouldn't the easiest thing be to just treat add a containerid to the
>> process context like auid.
>
> I believe so. At least that was the point I was trying to get across
> when I first jumped into this thread.
It sounds nice but containers are not just a per process construct.
Sometimes you might know anamespace but not which process instigated
action to happen on that namespace.
>> Then make it a privileged operation to set it. Then tools that care about
>> auditing like docker can set the ID
>> and remove the Capability from it sub processes if it cares. All
>> processes adopt parent processes containerid.
>> Now containers can be audited and as long as userspace is written
>> correctly nested containers can either override the containerid or not
>> depending on what the audit rules are.
>
> This part I'm still less certain on. I agree that setting the
> container ID should be privileged in some sense, but the kernel
> shouldn't *require* privilege to create a new container (however the
> user chooses to define it). Simply requiring privilege to set the
> container ID and failing silently may be sufficient.
My hope is as things mature fewer and fewer container things will need
any special privilege to create.
I think it needs to start with a clear definition of what is wanted and
then working backwards through which messages in which contexts you want
to have your magic bits.
Eric
next prev parent reply other threads:[~2015-05-16 14:51 UTC|newest]
Thread overview: 54+ 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 ` [PATCH V6 01/10] namespaces: expose ns_entries 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 ` [PATCH V6 03/10] audit: log namespace ID numbers 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 ` [PATCH V6 05/10] audit: log creation and deletion of namespace instances Richard Guy Briggs
2015-05-05 14:22 ` Steve Grubb
2015-05-05 14:31 ` Aristeu Rozanski
2015-05-05 14:46 ` Steve Grubb
2015-05-05 14:56 ` Eric W. Biederman
2015-05-05 15:16 ` Steve Grubb
2015-05-12 19:57 ` Richard Guy Briggs
2015-05-14 14:57 ` Steve Grubb
2015-05-14 15:42 ` Eric W. Biederman
2015-05-14 16:21 ` Steve Grubb
2015-05-15 2:03 ` Richard Guy Briggs
2015-05-14 19:19 ` Paul Moore
2015-05-15 1:31 ` Eric W. Biederman
2015-05-15 2:25 ` Richard Guy Briggs
2015-05-15 13:17 ` Steve Grubb
2015-05-15 14:51 ` Eric W. Biederman
2015-05-15 21:01 ` Paul Moore
2015-05-15 2:32 ` Richard Guy Briggs
2015-05-15 6:23 ` Andy Lutomirski
2015-05-15 12:38 ` Steve Grubb
2015-05-15 13:17 ` Andy Lutomirski
2015-05-15 21:05 ` Paul Moore
2015-05-16 9:46 ` Daniel J Walsh
2015-05-16 12:16 ` Paul Moore
2015-05-16 14:46 ` Eric W. Biederman [this message]
2015-05-16 22:49 ` Paul Moore
2015-05-19 13:09 ` Richard Guy Briggs
2015-05-19 14:27 ` Paul Moore
2015-05-15 0:48 ` Richard Guy Briggs
2015-05-15 20:26 ` Paul Moore
[not found] ` <CAA4jN2bgynVTwF+owtXgq06JMLQJpy_qokpD0mAguNYeDxmh1A@mail.gmail.com>
2015-05-15 2:11 ` Richard Guy Briggs
2015-05-15 13:19 ` Daniel J Walsh
2015-05-15 20:42 ` Paul Moore
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 ` [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags Richard Guy Briggs
2015-04-17 8:18 ` Peter Zijlstra
2015-04-17 15:42 ` Richard Guy Briggs
2015-04-17 17:41 ` Peter Zijlstra
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 ` [PATCH V6 10/10] audit: emit AUDIT_NS_INFO record with AUDIT_VIRT_CONTROL record Richard Guy Briggs
2015-04-21 4:33 ` [PATCH V6 00/10] namespaces: log namespaces per task Eric W. Biederman
2015-04-23 3:07 ` Richard Guy Briggs
2015-04-23 20:44 ` Richard Guy Briggs
2015-04-24 19:36 ` Eric W. Biederman
2015-04-28 2:05 ` Richard Guy Briggs
2015-04-28 2:16 ` Eric W. Biederman
2015-05-08 14:42 ` 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=87r3qgpol6.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=containers@lists.linux-foundation.org \
--cc=dwalsh@redhat.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=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=pmoore@redhat.com \
--cc=rgb@redhat.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).