From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: Regarding Auditd fails to start Date: Wed, 3 Feb 2016 11:01:57 -0500 Message-ID: <20160203160157.GC27528@madcap2.tricolour.ca> References: <20160203121619.5b293913@ivy-bridge> <20160203150827.0a154257@ivy-bridge> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: Sowndarya K , Linux-audit@redhat.com List-Id: linux-audit@redhat.com On 16/02/03, Paul Moore wrote: > On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb wrote: > > On Wed, 3 Feb 2016 07:57:52 -0500 > > Paul Moore wrote: > > > >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb wrote: > >> > On Wed, 3 Feb 2016 15:34:09 +0530 > >> > Sowndarya K 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 -- Richard Guy Briggs 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