Re: Linux-audit Digest, Vol 137, Issue 3

How do *I* can get the complete code change of the following patch set https://www.redhat.com/archives/linux-audit/2013-October/msg00048.html ?

On Thu, Feb 4, 2016 at 10:30 PM, <linux-audit-request(a)redhat.com&gt; wrote: > Send Linux-audit mailing list submissions to > linux-audit(a)redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/linux-audit > or, via email, send a message with subject or body 'help' to > linux-audit-request(a)redhat.com > > You can reach the person managing the list at > linux-audit-owner(a)redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linux-audit digest..." > > > Today's Topics: > > 1. Re: Regarding Auditd fails to start (Richard Guy Briggs) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 4 Feb 2016 05:15:57 -0500 > From: Richard Guy Briggs <rgb(a)redhat.com&gt; > To: Sowndarya K <sowndaryak18(a)gmail.com&gt; > Cc: linux-audit(a)redhat.com > Subject: Re: Regarding Auditd fails to start > Message-ID: <20160204101557.GD27528(a)madcap2.tricolour.ca&gt; > Content-Type: text/plain; charset=us-ascii > > On 16/02/04, Sowndarya K wrote: > > Thanks for your valuable response Richard!! > > Better late than never! (Re-adding the mailing list for openness and > information sharing.) > > > Now what I am facing as a problem is when I run auditd inside two > different > > containers,the recent one which has started the auditd service is logging > > all the processes which are created in other containers as well.How do I > > take care of it in such a way that container specific process records > > should be logged at each respective containers . > > This should not be possible for the definition of container that > immediately comes to mind with any existing kernel I know of. How do > you define a container? In particular from my point of interest, which > namespaces are cloned? It should not be possible if the user or pid > namespace has been cloned since the kernel explicitly blocks these for > the time being. I suspect neither one has been cloned and you are > seeing symptoms of RHBZ #1253123 which allows more than one auditd to > exist in the initial namespaces. This has been addressed in Paul > Moore's upstream kernel audit git tree as 133e1e5 to prevent this from > happenning unless you have also run into RHBZ #1243308 that was a > netlink rhashtable issue which should already be fixed in upstream > kernels. > > > On Wed, Feb 3, 2016 at 9:31 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; > wrote: > > > On 16/02/03, Paul Moore wrote: > > > > On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb(a)redhat.com&gt; > wrote: > > > > > On Wed, 3 Feb 2016 07:57:52 -0500 > > > > > Paul Moore <paul(a)paul-moore.com&gt; wrote: > > > > >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb(a)redhat.com&gt; > wrote: > > > > >> > On Wed, 3 Feb 2016 15:34:09 +0530 > > > > >> > Sowndarya K <sowndaryak18(a)gmail.com&gt; wrote: > > > > >> >> I am running docker container without privileges and now > service > > > > >> >> auditd start fails to execute even I add capabilities to > docker. > > > > >> >> please try to help me as early as possible > > > > >> > > > > > >> > If auditd is being run inside a container, then it has problems > > > > >> > because the audit subsystem inside the kernel isn't container > > > > >> > aware/namespaced. I have recently made changes to auditd in svn > for > > > > >> > the next release which allows auditd to run as a log > _aggregator_ > > > > >> > inside a container. This means it has no knowledge of events > coming > > > > >> > from within the container but can act as an aggregator for > systems > > > > >> > doing remote logging. > > > > >> > > > > >> To add some commentary to this: we are not going to namespace the > > > > >> audit subsystem like other subsystems, but making audit *aware* of > > > > >> namespaces is on the todo list. > > > > > > > > > > OK. Suppose I go out and rent a virtualized server with root > access for > > > > > my web site. Turns out the company that is leasing me time used > > > > > containers as their method of virtualizing. my web site runs fine > in a > > > > > container so no big deal. However, as a customer, I would want > access > > > > > to the logs for my container directly in the container. As a > matter of > > > > > fact, its a PCI-DSS requirement to have access to those logs. > > > > > > > > > > I really think the audit system _has to be_ namespaced, somehow, > for > > > > > compliance reasons. > > > > > > > > Having access to audit events generated inside a namespace (or set of > > > > namespaces to be more specific), and only generated inside a > namespace > > > > (or set of ...), does not require the audit subsystem to be > > > > namespaced; however, it does require the audit subsystem to recognize > > > > namespaces and associate them with events so that they can be tagged > > > > and routed accordingly. Based on previous conversations, I suspect > we > > > > have the same goals/ideas and are just using different terminology. > I > > > > wouldn't worry too much about it at this point as that work is still > > > > in the early stages. > > > > > > I'm late in the conversation, but "what Steve and Paul said". A number > > > of discussions have already happenned concerning this idea and the goal > > > is to have auditd be able to run pretty much seamlessly inside a > > > container without influencing or compromising the auditd running in the > > > parent namespace(s). From what we have discussed, it appears most > > > likely that auditd will be anchored one per user namespace. > > > > > > > paul moore > > > > > > - RGB > > - RGB