Re: Can auditd run in lxc on centos7

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(a)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(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit