linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Simo Sorce <simo@redhat.com>,
	linux-audit@redhat.com, mszeredi@redhat.com,
	trondmy@primarydata.com, jlayton@redhat.com,
	Linux API <linux-api@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Carlos O'Donell <carlos@redhat.com>,
	cgroups@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linux Network Development <netdev@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Eric Paris <eparis@parisplace.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: RFC(v2): Audit Kernel Container IDs
Date: Tue, 17 Oct 2017 13:15:00 -0400	[thread overview]
Message-ID: <1982291.vr6V9CPzqu@x2> (raw)
In-Reply-To: <eb96144d-4ab5-7f9f-de18-b296db35a00a@schaufler-ca.com>

On Tuesday, October 17, 2017 12:43:18 PM EDT Casey Schaufler wrote:
> > The idea is that processes spawned into a container would be labelled
> > by the container orchestration system.  It's unclear what should happen
> > to processes using nsenter after the fact, but policy for that should
> > be up to the orchestration system.
> 
> I'm fine with that. The user space policy can be anything y'all like.

I think there should be a login event.


> > The label will be used as a tag for audit information.
> 
> Deep breath ...
> 
> Which *is* a kernel security policy mechanism. Since the "label"
> is part of the audit information that the kernel is guaranteeing
> changing it would be covered by CAP_AUDIT_CONTROL. If the kernel
> does not use the "label" for any other purpose this is the only
> capability that makes sense for it.

I agree. The ability to set the container label grants the ability to evade 
rules or modify audit rules. CAP_AUDIT_CONTROL makes sense to me.


> > I think you were missing label inheritance above.
> > 
> > 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.

Yes. We have the same problem with loginuid. There are restrictions on who can 
change it once set. And then we made an immutable flag so that people that 
want a hard guarantee can get that.

-Steve

  reply	other threads:[~2017-10-17 17:15 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 [this message]
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
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=1982291.vr6V9CPzqu@x2 \
    --to=sgrubb@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --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=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).