Aristeu Rozanski <aris@xxxxxxxxxx> writes: > On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: >> Gao feng <gaofeng@xxxxxxxxxxxxxx> writes: >> >> > On 06/20/2013 11:02 AM, Gao feng wrote: >> >> If we don't tie audit to user namespace, there is still one problem. >> > >> > One more problem. some audit messages are generated by some net subsystem >> > such as netfilter. If we don't tie audit to user namespace, we have no >> > idea where these audit messages should go. there is no relationship between >> > net namespace and audit namespace while we can get user namespace through >> > net user namespace. >> >> I am in favor of the user namespace tie in. >> >> I am in favor of running a per user namespace audit filter once per user >> namespace walking up the user namespace hierarchy. Each filter would >> deliver messages to a different userspace audit daemon. >> >> Until we agreement to go that far I am not certain the kernel generated >> audit messages should go anywhere except to the global audit daemon. >> >> I think on an individual basis we can look at kernel audit messages and >> see if they should go to just the global user namespace. Just the user >> namspace of the relevant network stack. Or if the message should go to >> the audit daemon of every user namespace that is an ancestor of some >> starting user namespace. >> >> But please let's error on the side of caution here. > > Let's say I'd like to use userns but still have a single and global > auditd. By definition the kernel auditd functionality is broken if we don't allow a global auditd. So that will be allowed. > Dropping the capability will be required for that? No. Dropping capabilities and being in a state where you can never interact with the primary audit context is required to safely have access to a subordinate audit context. Never being able to intereact with the primary audit context removes all possibility of confusing a privileged application and break the security model. Entering a user namespace by definition drops all capabilities in a non-recoverable way. Which makes being in a user namespace a sufficient condition to use a subordinate audit context. > That sounds > bad. The fact new user namespaces will want to control the separated > audit namespace doesn't require tie in. No. The fact that you can gain root privileges by executing a suid root application when not in a user namespace requires a tie in. In summary. A subordinate audit context is not safe if you can still execute a suid root application and become root. The interesting use case is inside of a user namespace, which never allows gaining capabilities outside of the user namespace. Which makes a tie in with user namespaces sensible, as it never allows subverting the current mechanisms and it is where people want the functionality. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
