From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [Part1 PATCH 00/22] Add namespace support for audit Date: Mon, 24 Jun 2013 12:03:48 -0700 Message-ID: <87a9mfl4a3.fsf@xmission.com> References: <1371606834-5802-1-git-send-email-gaofeng@cn.fujitsu.com> <20130619204927.GJ3212@redhat.com> <1371675095.16587.5.camel@dhcp137-13.rdu.redhat.com> <51C270AF.1080902@cn.fujitsu.com> <51C27266.3060909@cn.fujitsu.com> <87y5a4phlm.fsf@xmission.com> <20130624150237.GA3535@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130624150237.GA3535-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (Aristeu Rozanski's message of "Mon, 24 Jun 2013 11:02:37 -0400") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Eric Paris , linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, matthltc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org List-Id: containers.vger.kernel.org Aristeu Rozanski writes: > On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: >> Gao feng 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