Regarding Auditd fails to start

[Richard Guy Briggs]

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 at redhat.com> wrote:
> > 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

- 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