From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>
Cc: Daniel J Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-kernel\@vger.kernel.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
Network Development
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux FS Devel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Eric Paris <eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.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-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Paul Moore's message of "Sat, 16 May 2015 08:16:55 -0400")
Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> writes:
> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1429252659.git.rgb@redhat.com>
[not found] ` <cover.1429252659.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-17 7:35 ` [PATCH V6 05/10] audit: log creation and deletion of namespace instances 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:31 ` Aristeu Rozanski
[not found] ` <20150505143119.GA4350-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-05 14:46 ` Steve Grubb
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-12 19:57 ` Richard Guy Briggs
[not found] ` <20150512195759.GA9832-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2015-05-14 14:57 ` Steve Grubb
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-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
[not found] ` <87bnhmbp8e.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
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
[not found] ` <20150515023221.GC965-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
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 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
[not found] ` <CAHC9VhRKSK9=9qPF3dgALS=x1g3LinNeQvuhNV5TvQ=D7Szuag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-16 14:46 ` Eric W. Biederman [this message]
[not found] ` <87r3qgpol6.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
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
[not found] ` <20150515004855.GB10526-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2015-05-15 1:10 ` Oren Laadan
[not found] ` <CAA4jN2bgynVTwF+owtXgq06JMLQJpy_qokpD0mAguNYeDxmh1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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 20:42 ` Paul Moore
2015-05-15 20:26 ` Paul Moore
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-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org \
--cc=pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
/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).