From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bob Beck" Subject: RE: Can auditd run in lxc on centos7 Date: Thu, 5 Apr 2018 12:52:24 -0400 Message-ID: <003501d3ccfe$79615de0$6c2419a0$@assurtech.com> References: <002a01d3ccfa$d247fda0$76d7f8e0$@assurtech.com> <117154045.faOI5Igds9@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <117154045.faOI5Igds9@x2> Content-Language: en-us List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: 'Steve Grubb' , linux-audit@redhat.com List-Id: linux-audit@redhat.com 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