Thanks for your valuable response Richard!!

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 .

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