Regarding Auditd fails to start

Regarding Auditd fails to start

[Sowndarya K]

[-- Attachment #1.1: Type: text/plain, Size: 203 bytes --]

Hello,


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


Thanks
Sowndarya K

[-- Attachment #1.2: Type: text/html, Size: 311 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Regarding Auditd fails to start

[Steve Grubb]

On Wed, 3 Feb 2016 15:34:09 +0530
Sowndarya K <sowndaryak18@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.

-Steve

Re: Regarding Auditd fails to start

[Paul Moore]

On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wed, 3 Feb 2016 15:34:09 +0530
> Sowndarya K <sowndaryak18@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.

-- 
paul moore
www.paul-moore.com

Re: Regarding Auditd fails to start

[Steve Grubb]

On Wed, 3 Feb 2016 07:57:52 -0500
Paul Moore <paul@paul-moore.com> wrote:

> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wed, 3 Feb 2016 15:34:09 +0530
> > Sowndarya K <sowndaryak18@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.

-Steve

Re: Regarding Auditd fails to start

[Paul Moore]

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

-- 
paul moore
www.paul-moore.com

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

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