ConditionKernelCommandLine=!audit=0 not respected in an nspawn container

[lahwaacz]

systemd version the issue has been seen with

246.3

Used distribution

Arch Linux

Expected behaviour you didn't see
When the host system is booted with audit=0 on the kernel command line, starting auditd.service in an nspawn container should be ignored due to ConditionKernelCommandLine=!audit=0.

Unexpected behaviour you saw
When the host system is booted with audit=0 on the kernel command line, starting auditd.service in an nspawn container results in a failed service:

# systemctl status auditd
* auditd.service - Security Auditing Service
     Loaded: loaded (/usr/lib/systemd/system/auditd.service; disabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Wed 2020-09-02 19:13:25 CEST; 22s ago
       Docs: man:auditd(8)
             https://github.com/linux-audit/audit-documentation
    Process: 50 ExecStart=/usr/bin/auditd (code=exited, status=1/FAILURE)

Sep 02 19:13:25 container systemd[1]: Starting Security Auditing Service...
Sep 02 19:13:25 container auditd[50]: Cannot change priority (Operation not permitted)
Sep 02 19:13:25 container auditd[50]: The audit daemon is exiting.
Sep 02 19:13:25 container systemd[1]: auditd.service: Control process exited, code=exited, status=1/FAILURE
Sep 02 19:13:25 container systemd[1]: auditd.service: Failed with result 'exit-code'.
Sep 02 19:13:25 container systemd[1]: Failed to start Security Auditing Service.

# cat /proc/cmdline 
initrd=\intel-ucode.img initrd=\initramfs-linux.img root=[...] rw quiet audit=0

# cat /usr/lib/systemd/system/auditd.service 
[Unit]
Description=Security Auditing Service
DefaultDependencies=no
## If auditd is sending or recieving remote logging, copy this file to
## /etc/systemd/system/auditd.service and comment out the first After and
## uncomment the second so that network-online.target is part of After.
## then comment the first Before and uncomment the second Before to remove
## sysinit.target from "Before".
After=local-fs.target systemd-tmpfiles-setup.service
##After=network-online.target local-fs.target systemd-tmpfiles-setup.service
Before=sysinit.target shutdown.target
##Before=shutdown.target
Conflicts=shutdown.target
RefuseManualStop=yes
ConditionKernelCommandLine=!audit=0
Documentation=man:auditd(8) https://github.com/linux-audit/audit-documentation

[Service]
Type=forking
PIDFile=/run/auditd.pid
ExecStart=/usr/bin/auditd
## To not use augenrules, copy this file to /etc/systemd/system/auditd.service
## and comment/delete the next line and uncomment the auditctl line.
## NOTE: augenrules expect any rules to be added to /etc/audit/rules.d/
ExecStartPost=-/usr/bin/augenrules --load
#ExecStartPost=-/usr/bin/auditctl -R /etc/audit/audit.rules
# By default we don't clear the rules on exit. To enable this, uncomment
# the next line after copying the file to /etc/systemd/system/auditd.service
#ExecStopPost=/usr/bin/auditctl -R /etc/audit/audit-stop.rules

[Install]
WantedBy=multi-user.target

Steps to reproduce the problem

1. Make sure that the host is booted with audit=0 on the kernel command line.
2. Create and start an nspawn container (I used Arch Linux on the host as well as in the container).
3. Run systemctl start auditd in the container.

[poettering]

well, if you pass "audit=0" on the nspawn cmdline, does it work then?

kernel cmdline is a weird concept for containers. In some cases you want the host cmdline to be used in other cases you want a container's cmdline (i.e. argv[] as passed to the container's PID 1) to be used. ConditionkernelCommandLine= actually checks the latter, and thus if you don#t specify "audit=0" you will get auditd in that container since it only uses that condition.

I am pretty sure auditd.service should actually carry ConditionCapability=CAP_AUDIT_CONTROL or so, given that we take that away in containers. Any chance you can file a bug against auditd asking for that?

I guess we should document clearly for ConditionkernelCommandLine= that it checks the containers cmdline

[lahwaacz]

Hmm, if I add audit=0 to systemd-nspawn, the ConditionKernelCommandLine=!audit=0 behaves as expected.

Interestingly, if you run systemd as PID 1 in a Docker container using CMD ["/usr/lib/systemd/systemd"] in a Dockerfile, the audit=0 is not in the argv[] list, but ConditionKernelCommandLine=!audit=0 still behaves as expected (I guess it somehow sees the host's kernel cmdline). What is the behaviour in other container types?

I'll submit a bug report for ConditionCapability=CAP_AUDIT_CONTROL to auditd.

[poettering]

I don't know Docker really, but unlike all other container managers they don#t want to be recognizable, hence systemd inside the container probably isn't aware it runs in a container. Docker really is not a nice player in this regard.