From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Jasen Subject: Re: Can auditd run in lxc on centos7 Date: Mon, 9 Apr 2018 15:52:23 -0400 Message-ID: <7f118072-2346-3c19-0bc0-c74015ba4e6d@gmail.com> References: <002a01d3ccfa$d247fda0$76d7f8e0$@assurtech.com> <117154045.faOI5Igds9@x2> <003501d3ccfe$79615de0$6c2419a0$@assurtech.com> <3283370.lk8oUfVqu5@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com [10.5.110.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4CC715FCAB for ; Mon, 9 Apr 2018 19:52:28 +0000 (UTC) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8B0002F30B8 for ; Mon, 9 Apr 2018 19:52:26 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id j73so10756567qke.6 for ; Mon, 09 Apr 2018 12:52:26 -0700 (PDT) Received: from [10.0.0.230] (pool-71-179-7-13.bltmmd.fios.verizon.net. [71.179.7.13]) by smtp.googlemail.com with ESMTPSA id b76sm890641qka.3.2018.04.09.12.52.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 12:52:24 -0700 (PDT) In-Reply-To: <3283370.lk8oUfVqu5@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: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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