From: Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
To: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH RFC] audit: provide namespace information in user originated records
Date: Wed, 20 Mar 2013 13:49:52 -0500 [thread overview]
Message-ID: <20130320184952.GA16488@sergelap> (raw)
In-Reply-To: <1363804924.2333.12.camel@localhost>
Quoting Eric Paris (eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote:
> > Quoting Aristeu Rozanski (arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> > > This is a bit fuzzy to me, perhaps due I'm not fully understanding
> > > userns implementation yet, so bear with me:
> > > I thought of changing so userns would not grant CAP_AUDIT_WRITE and
> > > CAP_AUDIT_CONTROL unless the process already has it (i.e. it'd require
> >
> > Seems like CAP_AUDIT_WRITE should be targeted against the
> > skb->netns->userns. Then CAP_AUDIT_WRITE can be treated like any other
> > capability. Last I knew (long time ago) you had to be in init_user_ns
> > to talk audit, but that's ok - this would just do the right thing in
> > any case.
>
> kauditd should be considered as existing in the init user namespace. So
> I'd think we'd want to check if the process had CAP_AUDIT_WRITE in the
> init user namespace and if so, allow it to send messages. Who care what
> *ns the process exists in. If it has it in the init namespace, go
> ahead. Thus the process that created the container would need
> CAP_AUDIT_WRITE in the init namespace for this to all work, right?
Yes. What I was suggesting is intended to work if that situation ever
changes. But I have zero complaints about doing it as you say, as I
doubt it ever will/ought to change.
That basically means CAP_AUDIT_WRITE would be worthless in a non-init
userns. That's fine - at least the rules would be consistent.
> /me also gets so confused about what caps mean in the userns world.
If the resource in question (like a network interface) belongs to a
namespace (netns) created by the userns in which the caller has the caps
in question, then privilege is granted.
Otherwise, not.
What you're saying above about CAP_AUDIT_WRITE is exactly right (for
how audit works right now).
> (/me has larger issues with the ns concept as a whole, but that boat
> sailed years and years ago)
-serge
next prev parent reply other threads:[~2013-03-20 18:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1363619405-6419-1-git-send-email-arozansk@redhat.com>
[not found] ` <1363619405-6419-9-git-send-email-arozansk@redhat.com>
2013-03-18 21:28 ` [PATCH RFC 8/8] audit: allow user records to be created inside a container Eric W. Biederman
[not found] ` <1363619405-6419-8-git-send-email-arozansk@redhat.com>
2013-03-18 21:44 ` [PATCH RFC 7/8] audit: report namespace information along with USER events Eric W. Biederman
2013-03-19 12:08 ` Aristeu Rozanski
[not found] ` <871ubc9yda.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2014-01-24 6:19 ` Richard Guy Briggs
[not found] ` <1363619405-6419-1-git-send-email-arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-18 22:16 ` [PATCH RFC] audit: provide namespace information in user originated records Eric W. Biederman
[not found] ` <877gl48iaz.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-19 12:24 ` Aristeu Rozanski
[not found] ` <20130319122408.GC20187-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-20 0:00 ` Eric W. Biederman
[not found] ` <874ng7gcst.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-20 15:12 ` Serge Hallyn
2013-03-20 15:45 ` Aristeu Rozanski
[not found] ` <20130320154503.GF20187-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-20 18:36 ` Serge Hallyn
2013-03-20 18:42 ` Eric Paris
2013-03-20 18:49 ` Serge Hallyn [this message]
2013-03-20 19:01 ` Eric Paris
2013-03-20 19:17 ` Aristeu Rozanski
2013-03-20 19:19 ` Serge Hallyn
2013-03-20 23:23 ` Eric W. Biederman
[not found] ` <87y5dh8xl7.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-21 1:46 ` Eric Paris
2013-03-21 2:21 ` Serge Hallyn
2013-03-21 4:48 ` Eric W. Biederman
2013-03-18 15:45 Aristeu Rozanski
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=20130320184952.GA16488@sergelap \
--to=serge.hallyn-gewih/nmzzlqt0dzr+alfa@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-audit-H+wXaHxf7aLQT0dZR+AlfA@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