All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tycho Andersen <tycho@tycho.ws>
To: Paul Moore <paul@paul-moore.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	Richard Guy Briggs <rgb@redhat.com>,
	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>,
	ebiederm@xmission.com, nhorman@tuxdriver.com
Subject: Re: [PATCH ghak90 V6 02/10] audit: add container id
Date: Thu, 30 May 2019 15:29:00 -0600	[thread overview]
Message-ID: <20190530212900.GC5739@cisco> (raw)
In-Reply-To: <CAHC9VhThLiQzGYRUWmSuVfOC6QCDmA75BDB7Eg7V8HX4x7ymQg@mail.gmail.com>

On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
> 
> [REMINDER: It is an "*audit* container ID" and not a general
> "container ID" ;)  Smiley aside, I'm not kidding about that part.]

This sort of seems like a distinction without a difference; presumably
audit is going to want to differentiate between everything that people
in userspace call a container. So you'll have to support all this
insanity anyway, even if it's "not a container ID".

> I'm not interested in supporting/merging something that isn't useful;
> if this doesn't work for your use case then we need to figure out what
> would work.  It sounds like nested containers are much more common in
> the lxc world, can you elaborate a bit more on this?
> 
> As far as the possible solutions you mention above, I'm not sure I
> like the per-userns audit container IDs, I'd much rather just emit the
> necessary tracking information via the audit record stream and let the
> log analysis tools figure it out.  However, the bigger question is how
> to limit (re)setting the audit container ID when you are in a non-init
> userns.  For reasons already mentioned, using capable() is a non
> starter for everything but the initial userns, and using ns_capable()
> is equally poor as it essentially allows any userns the ability to
> munge it's audit container ID (obviously not good).  It appears we
> need a different method for controlling access to the audit container
> ID.

One option would be to make it a string, and have it be append only.
That should be safe with no checks.

I know there was a long thread about what type to make this thing. I
think you could accomplish the append-only-ness with a u64 if you had
some rule about only allowing setting lower order bits than those that
are already set. With 4 bits for simplicity:

1100         # initial container id
1100 -> 1011 # not allowed
1100 -> 1101 # allowed, but now 1101 is set in stone since there are
             # no lower order bits left

There are probably fancier ways to do it if you actually understand
math :)

Since userns nesting is limited to 32 levels (right now, IIRC), and
you have 64 bits, this might be reasonable. You could just teach
container engines to use the first say N bits for themselves, with a 1
bit for the barrier at the end.

Tycho

WARNING: multiple messages have this Message-ID (diff)
From: Tycho Andersen <tycho@tycho.ws>
To: Paul Moore <paul@paul-moore.com>
Cc: nhorman@tuxdriver.com, Richard Guy Briggs <rgb@redhat.com>,
	linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	dhowells@redhat.com,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	netfilter-devel@vger.kernel.org, ebiederm@xmission.com,
	simo@redhat.com, netdev@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Eric Paris <eparis@parisplace.org>,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH ghak90 V6 02/10] audit: add container id
Date: Thu, 30 May 2019 15:29:00 -0600	[thread overview]
Message-ID: <20190530212900.GC5739@cisco> (raw)
In-Reply-To: <CAHC9VhThLiQzGYRUWmSuVfOC6QCDmA75BDB7Eg7V8HX4x7ymQg@mail.gmail.com>

On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
> 
> [REMINDER: It is an "*audit* container ID" and not a general
> "container ID" ;)  Smiley aside, I'm not kidding about that part.]

This sort of seems like a distinction without a difference; presumably
audit is going to want to differentiate between everything that people
in userspace call a container. So you'll have to support all this
insanity anyway, even if it's "not a container ID".

> I'm not interested in supporting/merging something that isn't useful;
> if this doesn't work for your use case then we need to figure out what
> would work.  It sounds like nested containers are much more common in
> the lxc world, can you elaborate a bit more on this?
> 
> As far as the possible solutions you mention above, I'm not sure I
> like the per-userns audit container IDs, I'd much rather just emit the
> necessary tracking information via the audit record stream and let the
> log analysis tools figure it out.  However, the bigger question is how
> to limit (re)setting the audit container ID when you are in a non-init
> userns.  For reasons already mentioned, using capable() is a non
> starter for everything but the initial userns, and using ns_capable()
> is equally poor as it essentially allows any userns the ability to
> munge it's audit container ID (obviously not good).  It appears we
> need a different method for controlling access to the audit container
> ID.

One option would be to make it a string, and have it be append only.
That should be safe with no checks.

I know there was a long thread about what type to make this thing. I
think you could accomplish the append-only-ness with a u64 if you had
some rule about only allowing setting lower order bits than those that
are already set. With 4 bits for simplicity:

1100         # initial container id
1100 -> 1011 # not allowed
1100 -> 1101 # allowed, but now 1101 is set in stone since there are
             # no lower order bits left

There are probably fancier ways to do it if you actually understand
math :)

Since userns nesting is limited to 32 levels (right now, IIRC), and
you have 64 bits, this might be reasonable. You could just teach
container engines to use the first say N bits for themselves, with a 1
bit for the barrier at the end.

Tycho

  reply	other threads:[~2019-05-30 21:58 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09  3:39 [PATCH ghak90 V6 00/10] audit: implement container identifier Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 01/10] audit: collect audit task parameters Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 02/10] audit: add container id Richard Guy Briggs
2019-05-29 14:57   ` Tycho Andersen
2019-05-29 15:29     ` Paul Moore
2019-05-29 15:29       ` Paul Moore
2019-05-29 15:34       ` Tycho Andersen
2019-05-29 16:03         ` Paul Moore
2019-05-29 22:28           ` Tycho Andersen
2019-05-29 22:39             ` Paul Moore
2019-05-30 17:09               ` Serge E. Hallyn
2019-05-30 19:29                 ` Paul Moore
2019-05-30 21:29                   ` Tycho Andersen [this message]
2019-05-30 21:29                     ` Tycho Andersen
2019-05-30 23:26                     ` Paul Moore
2019-05-31  0:20                       ` Richard Guy Briggs
2019-05-31 12:44                         ` Paul Moore
2019-06-03 20:24                           ` Steve Grubb
2019-06-18 22:12                             ` Paul Moore
2019-06-18 22:12                               ` Paul Moore
2019-06-18 22:46                               ` Richard Guy Briggs
2019-07-08 18:12                       ` Richard Guy Briggs
2019-07-08 20:43                         ` Paul Moore
2019-07-08 20:43                           ` Paul Moore
2019-07-15 21:09                         ` Paul Moore
2019-07-16 15:37                           ` Richard Guy Briggs
2019-07-16 16:08                             ` Paul Moore
2019-07-16 16:26                               ` Richard Guy Briggs
2019-07-16 16:26                                 ` Richard Guy Briggs
2019-07-08 18:05                   ` Richard Guy Briggs
2019-07-15 21:04                     ` Paul Moore
2019-07-15 21:04                       ` Paul Moore
2019-07-16 22:03                       ` Richard Guy Briggs
2019-07-16 23:30                         ` Paul Moore
2019-07-18  0:51                           ` Richard Guy Briggs
2019-07-18  0:51                             ` Richard Guy Briggs
2019-07-18 21:52                             ` Paul Moore
2019-07-19 16:00                               ` Eric W. Biederman
2019-07-19 22:41                                 ` Burn Alting
2019-07-20  2:19                                 ` James Bottomley
2019-07-19 15:32                             ` Eric W. Biederman
2019-07-08 17:51       ` Richard Guy Briggs
2019-07-15 20:38         ` Paul Moore
2019-07-16 19:38           ` Richard Guy Briggs
2019-07-16 21:39             ` Paul Moore
2019-07-19 16:07   ` Eric W. Biederman
2019-04-09  3:39 ` [PATCH ghak90 V6 03/10] audit: read container ID of a process Richard Guy Briggs
2019-07-19 16:03   ` Eric W. Biederman
2019-07-19 17:05     ` Richard Guy Briggs
2019-07-19 17:05       ` Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 04/10] audit: log container info of syscalls Richard Guy Briggs
2019-05-29 22:15   ` Paul Moore
2019-05-29 22:15     ` Paul Moore
2019-05-30 13:08     ` Ondrej Mosnacek
2019-05-30 14:08       ` Richard Guy Briggs
2019-05-30 14:34         ` Paul Moore
2019-04-09  3:39 ` [PATCH ghak90 V6 05/10] audit: add contid support for signalling the audit daemon Richard Guy Briggs
2019-04-09 12:57   ` Ondrej Mosnacek
2019-04-09 13:40     ` Paul Moore
2019-04-09 13:48       ` Neil Horman
2019-04-09 14:00         ` Ondrej Mosnacek
2019-04-09 14:07         ` Paul Moore
2019-04-09 13:53       ` Richard Guy Briggs
2019-04-09 14:08         ` Paul Moore
2019-04-09 13:46     ` Neil Horman
2019-04-09  3:39 ` [PATCH ghak90 V6 06/10] audit: add support for non-syscall auxiliary records Richard Guy Briggs
2019-04-09  3:39   ` Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 07/10] audit: add containerid support for user records Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 08/10] audit: add containerid filtering Richard Guy Briggs
2019-05-29 22:16   ` Paul Moore
2019-05-30 14:19     ` Richard Guy Briggs
2019-05-30 14:34       ` Paul Moore
2019-05-30 20:37         ` Richard Guy Briggs
2019-05-30 20:45           ` Paul Moore
2019-05-30 20:45             ` Paul Moore
2019-05-30 21:10             ` Richard Guy Briggs
2019-05-30 21:10               ` Richard Guy Briggs
2019-04-09  3:39 ` [PATCH ghak90 V6 09/10] audit: add support for containerid to network namespaces Richard Guy Briggs
2019-04-09  3:39   ` Richard Guy Briggs
2019-05-29 22:17   ` Paul Moore
2019-05-29 22:17     ` Paul Moore
2019-05-30 14:15     ` Richard Guy Briggs
2019-05-30 14:32       ` Paul Moore
2019-04-09  3:39 ` [PATCH ghak90 V6 10/10] audit: NETFILTER_PKT: record each container ID associated with a netNS Richard Guy Briggs
2019-04-11 11:31 ` [PATCH ghak90 V6 00/10] audit: implement container identifier Richard Guy Briggs
2019-04-22 11:38 ` Neil Horman
2019-04-22 13:49   ` Paul Moore
2019-04-23 10:28     ` Neil Horman
2019-05-28 21:53     ` Daniel Walsh
2019-05-28 22:25       ` Richard Guy Briggs
2019-05-28 22:26       ` Paul Moore
2019-05-28 23:00         ` Steve Grubb
2019-05-29  0:43           ` Richard Guy Briggs
2019-05-29 12:02             ` Daniel Walsh
2019-05-29 13:17               ` Paul Moore
2019-05-29 14:07                 ` Daniel Walsh
2019-05-29 14:33                   ` Paul Moore
2019-05-29 13:14             ` Paul Moore
2019-05-29 22:26     ` Paul Moore
2019-05-30 13:08       ` Steve Grubb
2019-05-30 13:35         ` Paul Moore
2019-05-30 14:08           ` 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=20190530212900.GC5739@cisco \
    --to=tycho@tycho.ws \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhowells@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=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.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: link
Be 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.