| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 24 Jun 2013 12:03:48 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Aristeu Rozanski <aris@...hat.com> Cc: Gao feng <gaofeng@...fujitsu.com>, containers@...ts.linux-foundation.org, serge.hallyn@...ntu.com, linux-kernel@...r.kernel.org, Eric Paris <eparis@...hat.com>, linux-audit@...hat.com, matthltc@...ux.vnet.ibm.com, sgrubb@...hat.com Subject: Re: [Part1 PATCH 00/22] Add namespace support for audit Aristeu Rozanski <aris@...hat.com> writes: > On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: >> Gao feng <gaofeng@...fujitsu.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists