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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 24 Jun 2013 11:02:37 -0400
From:	Aristeu Rozanski <aris@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

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. Dropping the capability will be required for that? That sounds
bad. The fact new user namespaces will want to control the separated
audit namespace doesn't require tie in.

-- 
Aristeu

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ