Regarding Auditd fails to start

[Richard Guy Briggs]

On 16/02/03, Paul Moore wrote:
> On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Wed, 3 Feb 2016 07:57:52 -0500
> > Paul Moore <paul at paul-moore.com> wrote:
> >
> >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> >> > On Wed, 3 Feb 2016 15:34:09 +0530
> >> > Sowndarya K <sowndaryak18 at gmail.com> 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 <rbriggs at redhat.com>
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