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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Jun 2013 13:15:46 +0800
From:	Gao feng <gaofeng@...fujitsu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Eric Paris <eparis@...hat.com>,
	containers@...ts.linux-foundation.org, serge.hallyn@...ntu.com,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	matthltc@...ux.vnet.ibm.com, sgrubb@...hat.com
Subject: Re: [Part1 PATCH 00/22] Add namespace support for audit

On 06/21/2013 06:01 AM, 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.
> 

Agree, this sounds reasonable.

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

There are some audit messages that we sure where they should go, we can start
from them firstly.

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

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