Re: Can auditd run in lxc on centos7

[John Jasen <jjasen@gmail.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