All of lore.kernel.org
 help / color / mirror / Atom feed
* Can auditd run in lxc on centos7
@ 2018-04-05 16:26 Bob Beck
  2018-04-05 16:37 ` Steve Grubb
  0 siblings, 1 reply; 7+ messages in thread
From: Bob Beck @ 2018-04-05 16:26 UTC (permalink / raw)
  To: linux-audit


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

Hi,

 

I am attempting to run auditd in centos7 inside a lxc container.

 

Here is the log I get when I run auditd -f

 

onfig file /etc/audit/auditd.conf opened for parsing

log_file_parser called with: /var/log/audit.log

log_format_parser called with: RAW

log_group_parser called with: root

priority_boost_parser called with: 4

flush_parser called with: INCREMENTAL

freq_parser called with: 20

num_logs_parser called with: 5

qos_parser called with: lossy

dispatch_parser called with: /usr/sbin/audispd

name_format_parser called with: NONE

max_log_size_parser called with: 6

max_log_size_action_parser called with: ROTATE

space_left_parser called with: 75

space_action_parser called with: SYSLOG

action_mail_acct_parser called with: root

admin_space_left_parser called with: 50

admin_space_left_action_parser called with: SUSPEND

disk_full_action_parser called with: SUSPEND

disk_error_action_parser called with: SUSPEND

tcp_listen_queue_parser called with: 5

tcp_max_per_addr_parser called with: 1

tcp_client_max_idle_parser called with: 0

enable_krb5_parser called with: no

GSSAPI support is not enabled, ignoring value at line 30

krb5_principal_parser called with: auditd

GSSAPI support is not enabled, ignoring value at line 31

Started dispatcher: /usr/sbin/audispd pid: 3028

type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t res=success

config_manager init complete

Error sending status request (Connection refused)

Error sending enable request (Connection refused)

type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
auid=4294967295 pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
res=failed

Unable to set initial audit startup state to 'enable', exiting

The audit daemon is exiting.

Error setting audit daemon pid (Connection refused)


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

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Can auditd run in lxc on centos7
  2018-04-05 16:26 Can auditd run in lxc on centos7 Bob Beck
@ 2018-04-05 16:37 ` Steve Grubb
  2018-04-05 16:52   ` Bob Beck
  0 siblings, 1 reply; 7+ messages in thread
From: Steve Grubb @ 2018-04-05 16:37 UTC (permalink / raw)
  To: linux-audit

On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> Hi,
> 
> I am attempting to run auditd in centos7 inside a lxc container.

It can run inside a container only as an aggregating server. Meaning that it 
cannot audit the host system, but rather collect logs from remote systems. To 
do this, set  local_events = no. This was added in audit-2.5.2.


> Here is the log I get when I run auditd -f
> 
> config file /etc/audit/auditd.conf opened for parsing
> 
> log_file_parser called with: /var/log/audit.log
> 
> log_format_parser called with: RAW
> 
> log_group_parser called with: root
> 
> priority_boost_parser called with: 4
> 
> flush_parser called with: INCREMENTAL
> 
> freq_parser called with: 20
> 
> num_logs_parser called with: 5
> 
> qos_parser called with: lossy
> 
> dispatch_parser called with: /usr/sbin/audispd
> 
> name_format_parser called with: NONE
> 
> max_log_size_parser called with: 6
> 
> max_log_size_action_parser called with: ROTATE
> 
> space_left_parser called with: 75
> 
> space_action_parser called with: SYSLOG
> 
> action_mail_acct_parser called with: root
> 
> admin_space_left_parser called with: 50
> 
> admin_space_left_action_parser called with: SUSPEND
> 
> disk_full_action_parser called with: SUSPEND
> 
> disk_error_action_parser called with: SUSPEND
> 
> tcp_listen_queue_parser called with: 5
> 
> tcp_max_per_addr_parser called with: 1
> 
> tcp_client_max_idle_parser called with: 0
> 
> enable_krb5_parser called with: no
> 
> GSSAPI support is not enabled, ignoring value at line 30
> 
> krb5_principal_parser called with: auditd
> 
> GSSAPI support is not enabled, ignoring value at line 31
> 
> Started dispatcher: /usr/sbin/audispd pid: 3028
> 
> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t res=success
> 
> config_manager init complete
> 
> Error sending status request (Connection refused)
> 
> Error sending enable request (Connection refused)
> 
> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> auid=4294967295 pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
> res=failed
> 
> Unable to set initial audit startup state to 'enable', exiting
> 
> The audit daemon is exiting.
> 
> Error setting audit daemon pid (Connection refused)

Yep. That is what you get when trying to audit the host from a unprivileged 
container. Container support in the kernel is still an ongoing project.

-Steve

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Can auditd run in lxc on centos7
  2018-04-05 16:37 ` Steve Grubb
@ 2018-04-05 16:52   ` Bob Beck
  2018-04-05 16:57     ` Richard Guy Briggs
  2018-04-05 18:28     ` Steve Grubb
  0 siblings, 2 replies; 7+ messages in thread
From: Bob Beck @ 2018-04-05 16:52 UTC (permalink / raw)
  To: 'Steve Grubb', linux-audit

Thanks for your quick reply.

Do you mean that it logs events from within the 1 specific lxc container
in which it is running but not the host VM?

Bob

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Thursday, April 05, 2018 12:37 PM
To: linux-audit@redhat.com
Cc: Bob Beck
Subject: Re: Can auditd run in lxc on centos7

On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> Hi,
> 
> I am attempting to run auditd in centos7 inside a lxc container.

It can run inside a container only as an aggregating server. Meaning that it
cannot audit the host system, but rather collect logs from remote systems.
To do this, set  local_events = no. This was added in audit-2.5.2.


> Here is the log I get when I run auditd -f
> 
> config file /etc/audit/auditd.conf opened for parsing
> 
> log_file_parser called with: /var/log/audit.log
> 
> log_format_parser called with: RAW
> 
> log_group_parser called with: root
> 
> priority_boost_parser called with: 4
> 
> flush_parser called with: INCREMENTAL
> 
> freq_parser called with: 20
> 
> num_logs_parser called with: 5
> 
> qos_parser called with: lossy
> 
> dispatch_parser called with: /usr/sbin/audispd
> 
> name_format_parser called with: NONE
> 
> max_log_size_parser called with: 6
> 
> max_log_size_action_parser called with: ROTATE
> 
> space_left_parser called with: 75
> 
> space_action_parser called with: SYSLOG
> 
> action_mail_acct_parser called with: root
> 
> admin_space_left_parser called with: 50
> 
> admin_space_left_action_parser called with: SUSPEND
> 
> disk_full_action_parser called with: SUSPEND
> 
> disk_error_action_parser called with: SUSPEND
> 
> tcp_listen_queue_parser called with: 5
> 
> tcp_max_per_addr_parser called with: 1
> 
> tcp_client_max_idle_parser called with: 0
> 
> enable_krb5_parser called with: no
> 
> GSSAPI support is not enabled, ignoring value at line 30
> 
> krb5_principal_parser called with: auditd
> 
> GSSAPI support is not enabled, ignoring value at line 31
> 
> Started dispatcher: /usr/sbin/audispd pid: 3028
> 
> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4 
> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t 
> res=success
> 
> config_manager init complete
> 
> Error sending status request (Connection refused)
> 
> Error sending enable request (Connection refused)
> 
> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> auid=4294967295 pid=3026 uid=0 ses=4294967295 
> subj=system_u:system_r:init_t res=failed
> 
> Unable to set initial audit startup state to 'enable', exiting
> 
> The audit daemon is exiting.
> 
> Error setting audit daemon pid (Connection refused)

Yep. That is what you get when trying to audit the host from a unprivileged
container. Container support in the kernel is still an ongoing project.

-Steve

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Can auditd run in lxc on centos7
  2018-04-05 16:52   ` Bob Beck
@ 2018-04-05 16:57     ` Richard Guy Briggs
  2018-04-05 18:28     ` Steve Grubb
  1 sibling, 0 replies; 7+ messages in thread
From: Richard Guy Briggs @ 2018-04-05 16:57 UTC (permalink / raw)
  To: Bob Beck; +Cc: linux-audit

On 2018-04-05 12:52, Bob Beck wrote:
> Thanks for your quick reply.
> 
> Do you mean that it logs events from within the 1 specific lxc container
> in which it is running but not the host VM?

No.  It can only receive audit events from another audit daemon over a
network socket.

There is active work being done to try to solve your problem, but it
isn't ready yet.

> Bob
> 
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com] 
> Sent: Thursday, April 05, 2018 12:37 PM
> To: linux-audit@redhat.com
> Cc: Bob Beck
> Subject: Re: Can auditd run in lxc on centos7
> 
> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> > Hi,
> > 
> > I am attempting to run auditd in centos7 inside a lxc container.
> 
> It can run inside a container only as an aggregating server. Meaning that it
> cannot audit the host system, but rather collect logs from remote systems.
> To do this, set  local_events = no. This was added in audit-2.5.2.
> 
> 
> > Here is the log I get when I run auditd -f
> > 
> > config file /etc/audit/auditd.conf opened for parsing
> > 
> > log_file_parser called with: /var/log/audit.log
> > 
> > log_format_parser called with: RAW
> > 
> > log_group_parser called with: root
> > 
> > priority_boost_parser called with: 4
> > 
> > flush_parser called with: INCREMENTAL
> > 
> > freq_parser called with: 20
> > 
> > num_logs_parser called with: 5
> > 
> > qos_parser called with: lossy
> > 
> > dispatch_parser called with: /usr/sbin/audispd
> > 
> > name_format_parser called with: NONE
> > 
> > max_log_size_parser called with: 6
> > 
> > max_log_size_action_parser called with: ROTATE
> > 
> > space_left_parser called with: 75
> > 
> > space_action_parser called with: SYSLOG
> > 
> > action_mail_acct_parser called with: root
> > 
> > admin_space_left_parser called with: 50
> > 
> > admin_space_left_action_parser called with: SUSPEND
> > 
> > disk_full_action_parser called with: SUSPEND
> > 
> > disk_error_action_parser called with: SUSPEND
> > 
> > tcp_listen_queue_parser called with: 5
> > 
> > tcp_max_per_addr_parser called with: 1
> > 
> > tcp_client_max_idle_parser called with: 0
> > 
> > enable_krb5_parser called with: no
> > 
> > GSSAPI support is not enabled, ignoring value at line 30
> > 
> > krb5_principal_parser called with: auditd
> > 
> > GSSAPI support is not enabled, ignoring value at line 31
> > 
> > Started dispatcher: /usr/sbin/audispd pid: 3028
> > 
> > type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4 
> > format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> > pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t 
> > res=success
> > 
> > config_manager init complete
> > 
> > Error sending status request (Connection refused)
> > 
> > Error sending enable request (Connection refused)
> > 
> > type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> > auid=4294967295 pid=3026 uid=0 ses=4294967295 
> > subj=system_u:system_r:init_t res=failed
> > 
> > Unable to set initial audit startup state to 'enable', exiting
> > 
> > The audit daemon is exiting.
> > 
> > Error setting audit daemon pid (Connection refused)
> 
> Yep. That is what you get when trying to audit the host from a unprivileged
> container. Container support in the kernel is still an ongoing project.
> 
> -Steve
> 
> 
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Can auditd run in lxc on centos7
  2018-04-05 16:52   ` Bob Beck
  2018-04-05 16:57     ` Richard Guy Briggs
@ 2018-04-05 18:28     ` Steve Grubb
  2018-04-09 19:52       ` John Jasen
  1 sibling, 1 reply; 7+ messages in thread
From: Steve Grubb @ 2018-04-05 18:28 UTC (permalink / raw)
  To: Bob Beck; +Cc: linux-audit

On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote:
> Thanks for your quick reply.
> 
> Do you mean that it logs events from within the 1 specific lxc container
> in which it is running but not the host VM?

Nope. It would only work as an aggregating server. Meaning it can collect 
logs from remote systems. But it cannot collect anything itself. Not from the 
container nor the host kernel. It can only log what comes across a tcp/ip 
connection from another auditd. This is a limitation of the kernel - which is 
being worked on currently.

-Steve

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, April 05, 2018 12:37 PM
> To: linux-audit@redhat.com
> Cc: Bob Beck
> Subject: Re: Can auditd run in lxc on centos7
> 
> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> > Hi,
> > 
> > I am attempting to run auditd in centos7 inside a lxc container.
> 
> It can run inside a container only as an aggregating server. Meaning that
> it cannot audit the host system, but rather collect logs from remote
> systems. To do this, set  local_events = no. This was added in
> audit-2.5.2.
> > Here is the log I get when I run auditd -f
> > 
> > config file /etc/audit/auditd.conf opened for parsing
> > 
> > log_file_parser called with: /var/log/audit.log
> > 
> > log_format_parser called with: RAW
> > 
> > log_group_parser called with: root
> > 
> > priority_boost_parser called with: 4
> > 
> > flush_parser called with: INCREMENTAL
> > 
> > freq_parser called with: 20
> > 
> > num_logs_parser called with: 5
> > 
> > qos_parser called with: lossy
> > 
> > dispatch_parser called with: /usr/sbin/audispd
> > 
> > name_format_parser called with: NONE
> > 
> > max_log_size_parser called with: 6
> > 
> > max_log_size_action_parser called with: ROTATE
> > 
> > space_left_parser called with: 75
> > 
> > space_action_parser called with: SYSLOG
> > 
> > action_mail_acct_parser called with: root
> > 
> > admin_space_left_parser called with: 50
> > 
> > admin_space_left_action_parser called with: SUSPEND
> > 
> > disk_full_action_parser called with: SUSPEND
> > 
> > disk_error_action_parser called with: SUSPEND
> > 
> > tcp_listen_queue_parser called with: 5
> > 
> > tcp_max_per_addr_parser called with: 1
> > 
> > tcp_client_max_idle_parser called with: 0
> > 
> > enable_krb5_parser called with: no
> > 
> > GSSAPI support is not enabled, ignoring value at line 30
> > 
> > krb5_principal_parser called with: auditd
> > 
> > GSSAPI support is not enabled, ignoring value at line 31
> > 
> > Started dispatcher: /usr/sbin/audispd pid: 3028
> > 
> > type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
> > format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> > pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
> > res=success
> > 
> > config_manager init complete
> > 
> > Error sending status request (Connection refused)
> > 
> > Error sending enable request (Connection refused)
> > 
> > type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> > auid=4294967295 pid=3026 uid=0 ses=4294967295
> > subj=system_u:system_r:init_t res=failed
> > 
> > Unable to set initial audit startup state to 'enable', exiting
> > 
> > The audit daemon is exiting.
> > 
> > Error setting audit daemon pid (Connection refused)
> 
> Yep. That is what you get when trying to audit the host from a unprivileged
> container. Container support in the kernel is still an ongoing project.
> 
> -Steve

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Can auditd run in lxc on centos7
  2018-04-05 18:28     ` Steve Grubb
@ 2018-04-09 19:52       ` John Jasen
  2018-04-09 20:59         ` Richard Guy Briggs
  0 siblings, 1 reply; 7+ messages in thread
From: John Jasen @ 2018-04-09 19:52 UTC (permalink / raw)
  To: linux-audit

As points of clarification:

would audit on the host have visibility into the container? (for
example, logging execve calls from certain users)

would pam_tty_audit running the host still be able to collect data upon
entering the container?

Thanks!




On 04/05/2018 02:28 PM, Steve Grubb wrote:
> On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote:
>> Thanks for your quick reply.
>>
>> Do you mean that it logs events from within the 1 specific lxc container
>> in which it is running but not the host VM?
> Nope. It would only work as an aggregating server. Meaning it can collect 
> logs from remote systems. But it cannot collect anything itself. Not from the 
> container nor the host kernel. It can only log what comes across a tcp/ip 
> connection from another auditd. This is a limitation of the kernel - which is 
> being worked on currently.
>
> -Steve
>
>> -----Original Message-----
>> From: Steve Grubb [mailto:sgrubb@redhat.com]
>> Sent: Thursday, April 05, 2018 12:37 PM
>> To: linux-audit@redhat.com
>> Cc: Bob Beck
>> Subject: Re: Can auditd run in lxc on centos7
>>
>> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
>>> Hi,
>>>
>>> I am attempting to run auditd in centos7 inside a lxc container.
>> It can run inside a container only as an aggregating server. Meaning that
>> it cannot audit the host system, but rather collect logs from remote
>> systems. To do this, set  local_events = no. This was added in
>> audit-2.5.2.
>>> Here is the log I get when I run auditd -f
>>>
>>> config file /etc/audit/auditd.conf opened for parsing
>>>
>>> log_file_parser called with: /var/log/audit.log
>>>
>>> log_format_parser called with: RAW
>>>
>>> log_group_parser called with: root
>>>
>>> priority_boost_parser called with: 4
>>>
>>> flush_parser called with: INCREMENTAL
>>>
>>> freq_parser called with: 20
>>>
>>> num_logs_parser called with: 5
>>>
>>> qos_parser called with: lossy
>>>
>>> dispatch_parser called with: /usr/sbin/audispd
>>>
>>> name_format_parser called with: NONE
>>>
>>> max_log_size_parser called with: 6
>>>
>>> max_log_size_action_parser called with: ROTATE
>>>
>>> space_left_parser called with: 75
>>>
>>> space_action_parser called with: SYSLOG
>>>
>>> action_mail_acct_parser called with: root
>>>
>>> admin_space_left_parser called with: 50
>>>
>>> admin_space_left_action_parser called with: SUSPEND
>>>
>>> disk_full_action_parser called with: SUSPEND
>>>
>>> disk_error_action_parser called with: SUSPEND
>>>
>>> tcp_listen_queue_parser called with: 5
>>>
>>> tcp_max_per_addr_parser called with: 1
>>>
>>> tcp_client_max_idle_parser called with: 0
>>>
>>> enable_krb5_parser called with: no
>>>
>>> GSSAPI support is not enabled, ignoring value at line 30
>>>
>>> krb5_principal_parser called with: auditd
>>>
>>> GSSAPI support is not enabled, ignoring value at line 31
>>>
>>> Started dispatcher: /usr/sbin/audispd pid: 3028
>>>
>>> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
>>> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
>>> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
>>> res=success
>>>
>>> config_manager init complete
>>>
>>> Error sending status request (Connection refused)
>>>
>>> Error sending enable request (Connection refused)
>>>
>>> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
>>> auid=4294967295 pid=3026 uid=0 ses=4294967295
>>> subj=system_u:system_r:init_t res=failed
>>>
>>> Unable to set initial audit startup state to 'enable', exiting
>>>
>>> The audit daemon is exiting.
>>>
>>> Error setting audit daemon pid (Connection refused)
>> Yep. That is what you get when trying to audit the host from a unprivileged
>> container. Container support in the kernel is still an ongoing project.
>>
>> -Steve
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Can auditd run in lxc on centos7
  2018-04-09 19:52       ` John Jasen
@ 2018-04-09 20:59         ` Richard Guy Briggs
  0 siblings, 0 replies; 7+ messages in thread
From: Richard Guy Briggs @ 2018-04-09 20:59 UTC (permalink / raw)
  To: John Jasen; +Cc: linux-audit

On 2018-04-09 15:52, John Jasen wrote:
> As points of clarification:
> 
> would audit on the host have visibility into the container? (for
> example, logging execve calls from certain users)

Yes, but filenames and inodes may not make sense if the filesystem isn't
mounted in the host mount namespace.

> would pam_tty_audit running the host still be able to collect data upon
> entering the container?

Yes, I believe so.

> Thanks!
> 
> On 04/05/2018 02:28 PM, Steve Grubb wrote:
> > On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote:
> >> Thanks for your quick reply.
> >>
> >> Do you mean that it logs events from within the 1 specific lxc container
> >> in which it is running but not the host VM?
> > Nope. It would only work as an aggregating server. Meaning it can collect 
> > logs from remote systems. But it cannot collect anything itself. Not from the 
> > container nor the host kernel. It can only log what comes across a tcp/ip 
> > connection from another auditd. This is a limitation of the kernel - which is 
> > being worked on currently.
> >
> > -Steve
> >
> >> -----Original Message-----
> >> From: Steve Grubb [mailto:sgrubb@redhat.com]
> >> Sent: Thursday, April 05, 2018 12:37 PM
> >> To: linux-audit@redhat.com
> >> Cc: Bob Beck
> >> Subject: Re: Can auditd run in lxc on centos7
> >>
> >> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> >>> Hi,
> >>>
> >>> I am attempting to run auditd in centos7 inside a lxc container.
> >> It can run inside a container only as an aggregating server. Meaning that
> >> it cannot audit the host system, but rather collect logs from remote
> >> systems. To do this, set  local_events = no. This was added in
> >> audit-2.5.2.
> >>> Here is the log I get when I run auditd -f
> >>>
> >>> config file /etc/audit/auditd.conf opened for parsing
> >>>
> >>> log_file_parser called with: /var/log/audit.log
> >>>
> >>> log_format_parser called with: RAW
> >>>
> >>> log_group_parser called with: root
> >>>
> >>> priority_boost_parser called with: 4
> >>>
> >>> flush_parser called with: INCREMENTAL
> >>>
> >>> freq_parser called with: 20
> >>>
> >>> num_logs_parser called with: 5
> >>>
> >>> qos_parser called with: lossy
> >>>
> >>> dispatch_parser called with: /usr/sbin/audispd
> >>>
> >>> name_format_parser called with: NONE
> >>>
> >>> max_log_size_parser called with: 6
> >>>
> >>> max_log_size_action_parser called with: ROTATE
> >>>
> >>> space_left_parser called with: 75
> >>>
> >>> space_action_parser called with: SYSLOG
> >>>
> >>> action_mail_acct_parser called with: root
> >>>
> >>> admin_space_left_parser called with: 50
> >>>
> >>> admin_space_left_action_parser called with: SUSPEND
> >>>
> >>> disk_full_action_parser called with: SUSPEND
> >>>
> >>> disk_error_action_parser called with: SUSPEND
> >>>
> >>> tcp_listen_queue_parser called with: 5
> >>>
> >>> tcp_max_per_addr_parser called with: 1
> >>>
> >>> tcp_client_max_idle_parser called with: 0
> >>>
> >>> enable_krb5_parser called with: no
> >>>
> >>> GSSAPI support is not enabled, ignoring value at line 30
> >>>
> >>> krb5_principal_parser called with: auditd
> >>>
> >>> GSSAPI support is not enabled, ignoring value at line 31
> >>>
> >>> Started dispatcher: /usr/sbin/audispd pid: 3028
> >>>
> >>> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
> >>> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> >>> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
> >>> res=success
> >>>
> >>> config_manager init complete
> >>>
> >>> Error sending status request (Connection refused)
> >>>
> >>> Error sending enable request (Connection refused)
> >>>
> >>> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> >>> auid=4294967295 pid=3026 uid=0 ses=4294967295
> >>> subj=system_u:system_r:init_t res=failed
> >>>
> >>> Unable to set initial audit startup state to 'enable', exiting
> >>>
> >>> The audit daemon is exiting.
> >>>
> >>> Error setting audit daemon pid (Connection refused)
> >> Yep. That is what you get when trying to audit the host from a unprivileged
> >> container. Container support in the kernel is still an ongoing project.
> >>
> >> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-04-09 20:59 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-05 16:26 Can auditd run in lxc on centos7 Bob Beck
2018-04-05 16:37 ` Steve Grubb
2018-04-05 16:52   ` Bob Beck
2018-04-05 16:57     ` Richard Guy Briggs
2018-04-05 18:28     ` Steve Grubb
2018-04-09 19:52       ` John Jasen
2018-04-09 20:59         ` Richard Guy Briggs

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.