Created attachment 1805361[details]
coredump file of systemd and audit log
Description of problem:
Systemd coredump and all services depends systemd can't work
Version-Release number of selected component (if applicable):
systemd-248.5-1.fc34.x86_64
How reproducible:
I don't know a exactly way to produce it. This first hapend two days ago when I run a docker command: docker run -it -v `pwd`:/workspace ubuntu /bin/sh.
Then the message tell me "systemd[1]: Freezing execution". Then I inspect it by
# cat /var/log/audit/audit.log| audit2why
type=AVC msg=audit(1626864773.201:998): avc: denied { prog_run } for pid=3877 comm="runc" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
type=AVC msg=audit(1626925225.222:1256): avc: denied { write } for pid=13721 comm="systemd-coredum" name="core_pattern" dev="proc" ino=15477 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
type=AVC msg=audit(1627171936.307:432): avc: denied { write } for pid=4673 comm="systemd-coredum" name="core_pattern" dev="proc" ino=335 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
First type error should be fixed by me, but I don't know why it produced always. The second has no fixed.
# cat /etc/selinux/custom/docker.te
module docker 1.0;
require {
type container_runtime_t;
type init_t;
class bpf prog_run;
}
#============= container_runtime_t ==============
allow container_runtime_t init_t:bpf prog_run;
Then I can find a coredump file just produced:
# LANG=en.US_UTF-8 l /var/lib/systemd/coredump
drwxr-xr-x. 2 root root 169 Jul 25 08:33 .
drwxr-xr-x. 11 root root 157 Jul 20 21:31 ..
-rw-r-----. 1 root root 752K Jul 25 08:12 core.systemd.0.9c98606c191b4f02bcea61747aec80f9.4672.1627171936000000.zst
-rw-r-----. 1 root root 816K Jul 22 11:40 core.systemd.0.dbe468c7311b43cbbf2f7ef74b855d93.13720.1626925225000000.zst
This bug can be solved by :
```
xxx.te
module custom 1.0;
require {
type container_runtime_t;
type systemd_coredump_t;
type usermodehelper_t;
type init_t;
class bpf prog_run;
class file write;
}
#============= container_runtime_t ==============
#!!!! This avc is allowed in the current policy
allow container_runtime_t init_t:bpf prog_run;
#============= systemd_coredump_t ==============
allow systemd_coredump_t usermodehelper_t:file write;
```
Comment 2Zbigniew Jędrzejewski-Szmek
2021-07-29 09:52:19 UTC
About the crash of systemd itself:
systemd-248.5-1.fc34.x86_64 was buggy. Please upgrade to systemd-248.6-1.fc34.x86_64.
As for the selinux denials: you might want to file a bug against the selinux policy package.
But I'd just ignore it… Systemd doesn't crash that often ;)
*** This bug has been marked as a duplicate of bug 1984651 ***
Created attachment 1805361 [details] coredump file of systemd and audit log Description of problem: Systemd coredump and all services depends systemd can't work Version-Release number of selected component (if applicable): systemd-248.5-1.fc34.x86_64 How reproducible: I don't know a exactly way to produce it. This first hapend two days ago when I run a docker command: docker run -it -v `pwd`:/workspace ubuntu /bin/sh. Then the message tell me "systemd[1]: Freezing execution". Then I inspect it by # cat /var/log/audit/audit.log| audit2why type=AVC msg=audit(1626864773.201:998): avc: denied { prog_run } for pid=3877 comm="runc" scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones. type=AVC msg=audit(1626925225.222:1256): avc: denied { write } for pid=13721 comm="systemd-coredum" name="core_pattern" dev="proc" ino=15477 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1627171936.307:432): avc: denied { write } for pid=4673 comm="systemd-coredum" name="core_pattern" dev="proc" ino=335 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. First type error should be fixed by me, but I don't know why it produced always. The second has no fixed. # cat /etc/selinux/custom/docker.te module docker 1.0; require { type container_runtime_t; type init_t; class bpf prog_run; } #============= container_runtime_t ============== allow container_runtime_t init_t:bpf prog_run; Then I can find a coredump file just produced: # LANG=en.US_UTF-8 l /var/lib/systemd/coredump drwxr-xr-x. 2 root root 169 Jul 25 08:33 . drwxr-xr-x. 11 root root 157 Jul 20 21:31 .. -rw-r-----. 1 root root 752K Jul 25 08:12 core.systemd.0.9c98606c191b4f02bcea61747aec80f9.4672.1627171936000000.zst -rw-r-----. 1 root root 816K Jul 22 11:40 core.systemd.0.dbe468c7311b43cbbf2f7ef74b855d93.13720.1626925225000000.zst