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

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 -- Richard Guy Briggs <rbriggs(a)redhat.com&gt; Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 ------------------------------ -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit End of Linux-audit Digest, Vol 137, Issue 3 *******************************************