TL;DR: Does anyone know how to work around the lack of auditd in Proxmox VE 4 lxc containers? Any tips appreciated!
Gory details:
Using Proxmox VE 4.0-50/d3a6b7e5 on Debian jessie with a 4.2.2 pve kernel, I've succeeded in provisioning nearly all of the stack I need in an LXC container ("All Gaul is occupied...") EXCEPT for auditd (which is needed unfortunately, so just disabling it is not an option). Auditd fails to start, and the reason seems plain enough from strace and browsing auditd and kernel source: no namespace support for audit ( e.g., the RFC described at lwn.net/Articles/571521/ ) has been implemented, so auditd bombs out with errors like:
# auditd -f -s nochange
Config file /etc/audit/auditd.conf opened for parsing
action_mail_acct_parser called with: root
admin_space_left_parser called with: 50
admin_space_left_action_parser called with: SUSPEND
disk_error_action_parser called with: SUSPEND
disk_full_action_parser called with: SUSPEND
qos_parser called with: lossy
dispatch_parser called with: /sbin/audispd
enable_krb5_parser called with: no
GSSAPI support is not enabled, ignoring value at line 10
flush_parser called with: INCREMENTAL
freq_parser called with: 20
krb5_principal_parser called with: auditd
GSSAPI support is not enabled, ignoring value at line 13
log_file_parser called with: /var/log/audit/audit.log
log_format_parser called with: RAW
log_group_parser called with: root
max_log_size_parser called with: 6
max_log_size_action_parser called with: ROTATE
name_format_parser called with: NONE
num_logs_parser called with: 5
priority_boost_parser called with: 4
space_left_parser called with: 75
space_action_parser called with: SYSLOG
tcp_client_max_idle_parser called with: 0
tcp_listen_queue_parser called with: 5
tcp_max_per_addr_parser called with: 1
Started dispatcher: /sbin/audispd pid: 6333
type=DAEMON_START msg=audit(1449106919.158:6202): auditd start, ver=2.3.7 format=raw kernel=4.2.2-1-pve auid=4294967295 pid=6331 subj=lxc-container-default (enforce) res=success
config_manager init complete
Error setting audit daemon pid (Operation not permitted)
type=DAEMON_ABORT msg=audit(1449106919.160:6203): auditd error halt, auid=4294967295 pid=6331 subj=lxc-container-default (enforce) res=failed
Unable to set audit pid, exiting
The audit daemon is exiting.
Error setting audit daemon pid (Operation not permitted)
Those EPERMs are the kernel ( lxr.free-electrons.com/source/kernel/audit.c?v=4.2#L669 ) refusing requests over a netlink socket to record auditd's pid (not to be confused with writing the pid to /var/run/auditd.pid). In other words, the container would be overwriting the host's audit subsystem, which wouldn't be ideal even if there was only one auditd needed in one container.
Suggestions? I can imagine:
1. A miracle occurs! Working namespace support for kernel 4.2.2 appears, that has just been hiding up someone's sleeve
2. Hacking auditd source (for use in the container), a large undertaking
3. Some kind of multi-tenant auditd, with shims in the container to talk to it
Thanks in advance for any ideas you might wish to share!
Karl Wiebe
Gory details:
Using Proxmox VE 4.0-50/d3a6b7e5 on Debian jessie with a 4.2.2 pve kernel, I've succeeded in provisioning nearly all of the stack I need in an LXC container ("All Gaul is occupied...") EXCEPT for auditd (which is needed unfortunately, so just disabling it is not an option). Auditd fails to start, and the reason seems plain enough from strace and browsing auditd and kernel source: no namespace support for audit ( e.g., the RFC described at lwn.net/Articles/571521/ ) has been implemented, so auditd bombs out with errors like:
# auditd -f -s nochange
Config file /etc/audit/auditd.conf opened for parsing
action_mail_acct_parser called with: root
admin_space_left_parser called with: 50
admin_space_left_action_parser called with: SUSPEND
disk_error_action_parser called with: SUSPEND
disk_full_action_parser called with: SUSPEND
qos_parser called with: lossy
dispatch_parser called with: /sbin/audispd
enable_krb5_parser called with: no
GSSAPI support is not enabled, ignoring value at line 10
flush_parser called with: INCREMENTAL
freq_parser called with: 20
krb5_principal_parser called with: auditd
GSSAPI support is not enabled, ignoring value at line 13
log_file_parser called with: /var/log/audit/audit.log
log_format_parser called with: RAW
log_group_parser called with: root
max_log_size_parser called with: 6
max_log_size_action_parser called with: ROTATE
name_format_parser called with: NONE
num_logs_parser called with: 5
priority_boost_parser called with: 4
space_left_parser called with: 75
space_action_parser called with: SYSLOG
tcp_client_max_idle_parser called with: 0
tcp_listen_queue_parser called with: 5
tcp_max_per_addr_parser called with: 1
Started dispatcher: /sbin/audispd pid: 6333
type=DAEMON_START msg=audit(1449106919.158:6202): auditd start, ver=2.3.7 format=raw kernel=4.2.2-1-pve auid=4294967295 pid=6331 subj=lxc-container-default (enforce) res=success
config_manager init complete
Error setting audit daemon pid (Operation not permitted)
type=DAEMON_ABORT msg=audit(1449106919.160:6203): auditd error halt, auid=4294967295 pid=6331 subj=lxc-container-default (enforce) res=failed
Unable to set audit pid, exiting
The audit daemon is exiting.
Error setting audit daemon pid (Operation not permitted)
Those EPERMs are the kernel ( lxr.free-electrons.com/source/kernel/audit.c?v=4.2#L669 ) refusing requests over a netlink socket to record auditd's pid (not to be confused with writing the pid to /var/run/auditd.pid). In other words, the container would be overwriting the host's audit subsystem, which wouldn't be ideal even if there was only one auditd needed in one container.
Suggestions? I can imagine:
1. A miracle occurs! Working namespace support for kernel 4.2.2 appears, that has just been hiding up someone's sleeve
2. Hacking auditd source (for use in the container), a large undertaking
3. Some kind of multi-tenant auditd, with shims in the container to talk to it
Thanks in advance for any ideas you might wish to share!
Karl Wiebe
Last edited:
