[PATCH RFC 00/48] Add namespace support for audit

[Gao feng]

On 06/11/2013 09:49 PM, Eric Paris wrote:
> On Tue, 2013-06-11 at 13:59 +0800, Gao feng wrote:
>> On 06/11/2013 05:24 AM, Serge E. Hallyn wrote:
>>> Quoting Gao feng (gaofeng at cn.fujitsu.com):
>>>> On 06/07/2013 06:47 AM, Serge Hallyn wrote:
>>>>> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
>>>>>> Quoting Gao feng (gaofeng at cn.fujitsu.com):
>>>>>>> On 05/07/2013 10:20 AM, Gao feng wrote:
> 
>> In my option, the audit rules(inode, tree_list, filter) , some of audit
>> controller related resources(enabled,pid,portid...) and skb queue, audit
>> netlink sockets,kauditd thread should be per-userns. The audit user message
>> which generated by the user in container should be per-userns too.
>>
>> Since netns is not implemented as a hierarchy, and the network related
>> resources are not global. so network related audit message should be per-userns too.
>>
>> The security related audit message should be send to init user namespace
>> as we discussed before. Maybe tty related audit message should be send
>> to init user namespace too, I have no idea now.
>>
>> The next step, I will post a new patchset which only make the audit user
>> message and the basic audit resource per userns. I think this patchset
>> will easy to be reviewed and accepted, And will not influence the host.
>> This patchset contains the below patches:
> 
> I think this would be easier for us do from a certification and
> doumentation PoV if we had an audit namespace, not tied to the user
> namespace.  creating a new audit namespace should require
> CAP_AUDIT_CONTROL in the user namespace which created the current audit
> namespace.
> 
Hi Eric,

You mean that like pid/net/user/uts.. namespace,audit namespace should be
created through system call clone with a new flag such as CLONE_NEWAUDIT?
If I didn't misunderstand you, I think it's better to tie audit namespace
to user namespace. since we don't have too much available flags for clone.


> Does that make sense?  I don't mind messages staying completely inside
> the current namespace, but that means we can't give unpriv users (even
> if they have priv in their user namespace) a new audit namespace...
> 

Sorry, I don't quite understand what the current namespace you mentioned here,
the audit namespace current tasks belong to?

upriv users can create new user namespace, in my implementation,the unpriv users
can have its own audit namespace when they create a new user namespace.

I guess I may misunderstand you, if I'm wrong, please correct me :)

Thanks,
Gao