4:04 a.m.
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
5:16 a.m.
On Wed, 3 Feb 2016 15:34:09 +0530
Sowndarya K <sowndaryak18(a)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
6:57 a.m.
On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wed, 3 Feb 2016 15:34:09 +0530
Sowndarya K <sowndaryak18(a)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
8:08 a.m.
On Wed, 3 Feb 2016 07:57:52 -0500
Paul Moore <paul(a)paul-moore.com> wrote:
On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Wed, 3 Feb 2016 15:34:09 +0530
> Sowndarya K <sowndaryak18(a)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
8:27 a.m.
On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wed, 3 Feb 2016 07:57:52 -0500
Paul Moore <paul(a)paul-moore.com> wrote:
> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > On Wed, 3 Feb 2016 15:34:09 +0530
> > Sowndarya K <sowndaryak18(a)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
10:01 a.m.
On 16/02/03, Paul Moore wrote:
On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Wed, 3 Feb 2016 07:57:52 -0500
> Paul Moore <paul(a)paul-moore.com> wrote:
>
>> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
>> > On Wed, 3 Feb 2016 15:34:09 +0530
>> > Sowndarya K <sowndaryak18(a)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(a)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
3245
days inactive
3245
days old
linux-audit@lists.linux-audit.osci.io
5 comments
4 participants
participants (4)
-
Paul Moore -
Richard Guy Briggs -
Sowndarya K -
Steve Grubb