On 06/21/2013 11:48 AM, Gao feng wrote: > On 06/20/2013 09:02 PM, Eric Paris wrote: >> On Thu, 2013-06-20 at 11:02 +0800, Gao feng wrote: >>> On 06/20/2013 04:51 AM, Eric Paris wrote: >>>> On Wed, 2013-06-19 at 16:49 -0400, Aristeu Rozanski wrote: >>>>> On Wed, Jun 19, 2013 at 09:53:32AM +0800, Gao feng wrote: >>>>>> This patchset is first part of namespace support for audit. >>>>>> in this patchset, the mainly resources of audit system have >>>>>> been isolated. the audit filter, rules havn't been isolated >>>>>> now. It will be implemented in Part2. We finished the isolation >>>>>> of user audit message in this patchset. >>>>>> >>>>>> I choose to assign audit to the user namespace. >>>>>> Right now,there are six kinds of namespaces, such as >>>>>> net, mount, ipc, pid, uts and user. the first five >>>>>> namespaces have special usage. the audit isn't suitable to >>>>>> belong to these five namespaces, And since the flag of system >>>>>> call clone is in short supply, we can't provide a new flag such >>>>>> as CLONE_NEWAUDIT to enable audit namespace separately. so the >>>>>> user namespace may be the best choice. >>>>> >>>>> I thought it was said on the last submission that to tie userns and >>>>> audit namespace would be a bad idea? >>>> >>>> I consider it a non-starter. unpriv users are allowed to launch their >>>> own user namespace. The whole point of audit is to have only a priv >>>> user be allowed to make changes. If you tied audit namespace to user >>>> namespace you grant an unpriv user the ability to modify audit. >>>> >>> >>> I understand your views. >>> >>> But ven the unpriv user are allowed to make changes, they can do no harm. >>> they can only make changes on the audit namespace they created.they can >>> only communicate with the audit namespace they created. >> >> Imagine I set up my machine to audit all user access to super secret >> information. With your patch set all an malicious user has to do is >> create a new user namespace. Now when he accesses the super secret >> information it will be logged inside the user namespace he created. So >> he can just dump those logs in the trash. >> > > No, my v1 patchset only log the user audit message(which generated through > auditctl -m "xxx") inside user namespace. > > I agree with that we should not simply log audit message in the child > audit namespace. for some global resource related audit messages, they > should be logged in init audit namespace too. > >> I believe that each audit namespace should require priv >> (CAP_AUDIT_CONTROL) in the user namespace that created the current audit >> namespace. So lets say the machine boots and we are in the init_user >> and init_audit namespace. Creating a new audit namespace should require >> CAP_AUDIT_CONTROL in the init_user namespace. If instead we spawned a >> new user namespace userns1 and try to create a new audit namespace, we >> should STILL check for CAP_AUDIT_CONTROL in the init_user namespace. >> > > Ok, I can add this permission check in next version, though this seems a > litter strictness when we make sure child audit namespace won't fool the > init audit namespace, > >> Assuming we've spawned auditns1 in userns1 and want to spawn auditns2 it >> should require CAP_AUDIT_CONTROL in userns1. So now you only have >> permission to change your audit config (create a new audit namespace) if >> you already had permission to change your current audit config. >> >> Now how to handle coding this... >> >> When the kernel receives an audit message on the netlink socket it can >> always check the current->[whatever] to figure out which audit namespace >> it came from. Then it can be processed accordingly... > > Yes, this situation is easy to handle, since we are in process context... > but in some situations, we are not running in process context... as I > mentioned, audit messages generated by netfilter rules. current process > is untrustable. we can only get meaningful net namespace in this situation. > Actually, it's meaningful to send net related audit messages to the user > namespace which creates this net namespace. > > >> >> Sending messages to the userspace auditd is a little more tricky. We >> need to somehow map the audit namespace to a socket connected to auditd >> in userspace. I'd imagine we'd have to either have per auditns backlog >> queues and run one kauditd per audit namespace, or we'd have to tag the >> skb's with the intended namespace somehow and then find the right socket >> in kauditd. Either way it doesn't seem too onerous (although I admit, I >> don't know how to code the per namespace kauditd right offhand) >> > > As I said in "[PATCH 04/22] netlink: Add compare function for netlink_table", > netlink and socket are private resources of net namespace. socket has no > idea which audit namespace it belongs to,unless we add a field to mark this. > Through I think we can archive audit namespace in your way,but maybe we should > hack into the net namespace. I don't think the network guys will like it. > > There is one more thing we have to do if we don't tie audit namespace to user > namespace. we have to implement the audit proc file(/proc/<pid>/ns/audit) and > the clone/unshare/setns parts. > > I still this my way is the simplest and can satisfy your requirement. > Ping... Eric, I need to know what's your comment.. Thanks _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
