From: Gao feng <gaofeng@cn.fujitsu.com>
To: Eric Paris <eparis@redhat.com>, ebiederm@xmission.com
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: [PATCH] audit: listen in all network namespaces
Date: Fri, 02 Aug 2013 09:48:32 +0800 [thread overview]
Message-ID: <51FB0FF0.1010607@cn.fujitsu.com> (raw)
In-Reply-To: <1375379837.20145.40.camel@dhcp137-13.rdu.redhat.com>
On 08/02/2013 01:57 AM, Eric Paris wrote:
> On Tue, 2013-07-30 at 13:22 -0400, Richard Guy Briggs wrote:
>> On Mon, Jul 22, 2013 at 11:20:57AM +0800, Gao feng wrote:
>>> On 07/20/2013 05:15 AM, Richard Guy Briggs wrote:
>>>> On Wed, Jul 17, 2013 at 11:54:21AM +0800, Gao feng wrote:
>>>>> Hi, Richard
>>>>>
>>>>> On 07/17/2013 04:32 AM, Richard Guy Briggs wrote:
>>>>>> Convert audit from only listening in init_net to use register_pernet_subsys()
>>>>>> to dynamically manage the netlink socket list.
>>>>>>
>>>>>> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>>>>>> ---
>>>>>
>>>>> Right now audit still can't be used in uninit pid/user namespace,
>>>>> Consider this, when user in uninit pid/user namespace is allowed
>>>>> to setup/run audit subsystem, since the kernel thread always runs
>>>>> in init pid namespace, so we can't get right net namespace through
>>>>> get_net_ns_by_pid, The audit information will be sent to incorrect
>>>>> net namespace by kernel thread.
>>>>>
>>>>> In my opinion, This patch is limited and nonextensile.
>
> I agree completely that this patch is limited and nonextensible. But it
> gets us where we should already be today. A single global kauditd and a
> single global auditd. Today if you spawn a new network namespace you
> cannot send messages to the kernel audit system. You cannot run auditd
> in uninit network namespace.
Yes, and you cannot run auditd in uninit pid/user namespace too.
> This is wrong. The kernel should take
> anything userspace wants to throw at it and it should send messages to
> auditd no matter where it lives. I see this is a good patch that should
> go in next window, and will likely get overwritten completely with your
> future work.
I'm ok if you want this patch in next window, but I have to say, The solutions
I can think out will almost revert or rewrite this patch.
>
> Now your patch handles this and so much more.
>
> I still detest the idea of tieing the audit namespace to the user
> namespace. My NAK still stands on any such patches.
>
> I'd think that disjoint namespaces (like networking) instead of
> hierarchical namespaces (like user) would be a lot easier to do. My
> thoughts have always been about completely disjoint audit namespaces and
> I may have missed the nuance of some of your discussion because it
> didn't really dawn on me you seem to have always been discussing
> hierarchical audit namespace.
Though user namespace is hierarchical, we can make auditns nonhierarchical even
tie it to userns. this depends on our decision/implementation, doesn't depend
on if we tie aduitns to userns.
>
> I'm wondering if we want/need both? If I decide to launch a whole
> distro inside a container I may not want it to be subject to any of the
> audit rules of the init namespace. disjoint namespaces are good. You
> don't seem to allow this, the init namespace audit rules would also
> apply.
>
we can isolate audit rules, auditns can have its own audit rules, and
take no effect on other auditns.
> I'm not saying hierarchical rules are bad, in fact I might be convinced
> they are adequate, I just can't bring myself to that conclusion yet.
> The conclusion I still feel comfortable with is that the user namespace
> is a whole of bag and I don't want it tied to audit.
>
Get it, I feel that you really don't like this idea, There are three reasons
I choose to tie auditns to userns.
1, all other namespace(net,pid,mnt,ipc..) has a "user_ns" pointer which point
to the user namespace, this user namespace is the creator of these namespace.
So in these namespaces, we can find out the auditns through {netns,pidns,ipcns}->user_ns->audit.
audit subsystem is a service layer, it should be available for other subsystems.
if we don't tie auditns to userns, we have to add an extra pointer for other
namespace, looks like this netns->auditns, pidns->auditns, ipcns->auditns.
2. if we don't tie auditns to userns, we have to find a way to create a new
auditns. the flags of clone is a problem.
3, there are already 6 kinds of namespaces, for me, I don't want to introduce
a complete new namespace(think about there are syslog,crypto... need to be
ioslated, there will be so much namespace...). I choose to extend the current
exist namespace and achieve the same feature.
I know it's not a very good solution,since userns totally has no relationship
with audit...
next prev parent reply other threads:[~2013-08-02 1:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 20:32 [PATCH] audit: listen in all network namespaces Richard Guy Briggs
2013-07-17 3:54 ` Gao feng
2013-07-19 21:15 ` Richard Guy Briggs
2013-07-22 3:20 ` Gao feng
2013-07-30 17:22 ` Richard Guy Briggs
2013-08-01 17:57 ` Eric Paris
2013-08-02 1:48 ` Gao feng [this message]
2013-08-02 13:21 ` Miloslav Trmač
2013-08-02 1:17 ` Gao feng
[not found] ` <1374006760-7687-1-git-send-email-rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-12-19 3:59 ` Gao feng
2013-12-19 3:59 ` Gao feng
[not found] ` <52B26F1A.9070308-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-12-19 18:40 ` Eric Paris
2013-12-19 18:40 ` Eric Paris
[not found] ` <1387478422.29366.33.camel-OjZBOOqb7SR7cYLChsl7DafLeoKvNuZc@public.gmane.org>
2013-12-20 1:35 ` Gao feng
2013-12-20 1:35 ` Gao feng
2013-12-20 2:46 ` Gao feng
2013-12-20 2:46 ` Gao feng
[not found] ` <52B3AF8F.5040607-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-12-20 3:11 ` Eric Paris
2013-12-20 3:11 ` Eric Paris
2013-12-20 3:45 ` Gao feng
2013-12-20 3:45 ` Gao feng
-- strict thread matches above, loose matches on Subject: below --
2013-07-16 20:15 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=51FB0FF0.1010607@cn.fujitsu.com \
--to=gaofeng@cn.fujitsu.com \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@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.