Linux-audit Digest, Vol 137, Issue 3

Mon Feb 8 11:08:17 UTC 2016

How do *I* can get the complete code change of the following patch set
https://www.redhat.com/archives/linux-audit/2013-October/msg00048.html ?

On Thu, Feb 4, 2016 at 10:30 PM, <linux-audit-request at redhat.com> wrote:

> Send Linux-audit mailing list submissions to
>         linux-audit at 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 at redhat.com
>
> You can reach the person managing the list at
>         linux-audit-owner at 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 at redhat.com>
> To: Sowndarya K <sowndaryak18 at gmail.com>
> Cc: linux-audit at redhat.com
> Subject: Re: Regarding Auditd fails to start
> Message-ID: <20160204101557.GD27528 at madcap2.tricolour.ca>
> 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 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
>
>
>
> ------------------------------
>
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
> End of Linux-audit Digest, Vol 137, Issue 3
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20160208/7fd5b942/attachment.htm>