linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Aleksa Sarai <asarai@suse.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	cgroups@vger.kernel.org, mszeredi@redhat.com,
	Andy Lutomirski <luto@kernel.org>,
	jlayton@redhat.com, "Carlos O'Donell" <carlos@redhat.com>,
	API <linux-api@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	linux-audit@redhat.com, Simo Sorce <simo@redhat.com>,
	Development <netdev@vger.kernel.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Eric Paris <eparis@parisplace.org>,
	Steve Grubb <sgrubb@redhat.com>,
	trondmy@primarydata.com
Subject: Re: RFC(v2): Audit Kernel Container IDs
Date: Thu, 19 Oct 2017 11:36:39 -0400	[thread overview]
Message-ID: <CAHC9VhTYF-MJm3ejWXE1H-eeXKaNBkeWKwdiKdj093xATYn7nQ@mail.gmail.com> (raw)
In-Reply-To: <871sm0j7bm.fsf@xmission.com>

On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Aleksa Sarai <asarai@suse.de> writes:
>>>> The security implications are that anything that can change the label
>>>> could also hide itself and its doings from the audit system and thus
>>>> would be used as a means to evade detection.  I actually think this
>>>> means the label should be write once (once you've set it, you can't
>>>> change it) ...
>>>
>>> Richard and I have talked about a write once approach, but the
>>> thinking was that you may want to allow a nested container
>>> orchestrator (Why? I don't know, but people always want to do the
>>> craziest things.) and a write-once policy makes that impossible.  If
>>> we punt on the nested orchestrator, I believe we can seriously think
>>> about a write-once policy to simplify things.
>>
>> Nested containers are a very widely used use-case (see LXC system containers,
>> inside of which people run other container runtimes). So I would definitely
>> consider it something that "needs to be supported in some way". While the LXC
>> guys might be a *tad* crazy, the use-case isn't. :P

No worries, we're all a little crazy in our own special ways ;)

Kidding aside, thanks for explaining the use case.

> Of course some of that gets to running auditd inside a container which
> we don't have yet either.
>
> So I think to start it is perfectly fine to figure out the non-nested
> case first and what makes sense there.  Then to sort out the nested
> container case.
>
> The solution might be that a process gets at most one id per ``audit
> namespace''.

In an attempt to stay on-topic, let's try to stick with "audit
container ID" or "container ID" if you must.  I really want to avoid
the term "audit namespace" simply because the term "namespace" implies
some things which we aren't planning on doing.

-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2017-10-19 15:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 14:14 RFC(v2): Audit Kernel Container IDs Richard Guy Briggs
2017-10-12 15:45 ` Steve Grubb
2017-10-19 19:57   ` Richard Guy Briggs
2017-10-19 23:11     ` Aleksa Sarai
2017-10-19 23:15       ` Aleksa Sarai
2017-10-20  2:25       ` Steve Grubb
2017-10-12 16:33 ` Casey Schaufler
2017-10-17  0:33   ` Richard Guy Briggs
2017-10-17  1:10     ` Casey Schaufler
2017-10-19  0:05       ` Richard Guy Briggs
2017-10-19 13:32         ` Casey Schaufler
2017-10-19 15:51           ` Paul Moore
2017-10-17  1:42     ` Steve Grubb
2017-10-17 12:31       ` Simo Sorce
2017-10-17 14:59         ` Casey Schaufler
2017-10-17 15:28           ` Simo Sorce
2017-10-17 15:44             ` James Bottomley
2017-10-17 16:43               ` Casey Schaufler
2017-10-17 17:15                 ` Steve Grubb
2017-10-17 17:57                   ` James Bottomley
2017-10-18  0:23                     ` Steve Grubb
2017-10-18 20:56               ` Paul Moore
2017-10-18 23:46                 ` Aleksa Sarai
2017-10-19  0:43                   ` Eric W. Biederman
2017-10-19 15:36                     ` Paul Moore [this message]
2017-10-19 16:25                       ` Eric W. Biederman
2017-10-19 17:47                         ` Paul Moore
2017-10-17 16:10             ` Casey Schaufler
2017-10-18 19:58         ` Paul Moore
2017-12-09 10:20   ` Mickaël Salaün
2017-12-09 18:28     ` Casey Schaufler
2017-12-11 16:30       ` Eric Paris
2017-12-11 16:52         ` Casey Schaufler
2017-12-11 19:37         ` Steve Grubb
2017-12-11 15:10     ` Richard Guy Briggs
2017-10-12 17:59 ` Eric W. Biederman
2017-10-13 13:43 ` Alan Cox

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=CAHC9VhTYF-MJm3ejWXE1H-eeXKaNBkeWKwdiKdj093xATYn7nQ@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=asarai@suse.de \
    --cc=carlos@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=jlayton@redhat.com \
    --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@kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sgrubb@redhat.com \
    --cc=simo@redhat.com \
    --cc=trondmy@primarydata.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).