Description of problem: Our cockpit tests [1] showed a failure related to insights and SELinux. Starting `insights-client --status` eventually starts insights-client-results.service, which then sometimes causes this: kernel: audit: type=1400 audit(1674736402.753:4): avc: denied { signull } for pid=6067 comm="gpg" scontext=system_u:system_r:gpg_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Version-Release number of selected component (if applicable): insights-client-3.1.7-11.el8.noarch selinux-policy-3.14.3-114.el8.noarch kernel-core-4.18.0-449.el8.x86_64 gnupg2-2.2.20-3.el8_6.x86_64 How reproducible: Really hard. I've ran this 20 times, and it did not reproduce. Full journal is at [2], but the interesting part is here: Jan 26 07:33:20 rhel-8-8-127-0-0-2-2201 systemd[1]: Starting Check for insights from Red Hat Cloud Services... Jan 26 07:33:22 rhel-8-8-127-0-0-2-2201 kernel: audit: type=1400 audit(1674736402.753:4): avc: denied { signull } for pid=6067 comm="gpg" scontext=system_u:system_r:gpg_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Jan 26 07:33:26 rhel-8-8-127-0-0-2-2201 systemd[1]: insights-client-results.service: Succeeded. Jan 26 07:33:26 rhel-8-8-127-0-0-2-2201 systemd[1]: Started Check for insights from Red Hat Cloud Services. I have no idea what "signull" means. If that rings a bell to the SELinux or insights developers, then maybe this is useful. If it doesn't, feel free to ignore this bug, as it's so hard to reproduce. [1] https://cockpit-logs.us-east-1.linodeobjects.com/pull-18251-20230126-114527-88aa850e-rhel-8-8/log.html#246 [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-18251-20230126-114527-88aa850e-rhel-8-8/TestSystemInfo-testInsightsStatus-rhel-8-8-127.0.0.2-2601-FAIL.log.gz
I am setting up an automatic tracker in https://github.com/cockpit-project/bots/issues/4318 , so that we can see how often this actually happens.
Hi Martin, signull means test for the existence of another process without sending a signal, in full auditing the denial reads type=PROCTITLE msg=audit(11/18/21 13:22:44.231:774) : proctitle=sudo -u staff cmd type=SYSCALL msg=audit(11/18/21 13:22:44.231:774) : arch=x86_64 syscall=kill success=no exit=EACCES(Permission denied) a0=0x1a2c a1=SIG0 a2=0x4 a3=0x7ffd93c089cf items=0 ppid=6747 pid=6748 auid=staff uid=root gid=staff euid=root suid=root fsuid=root egid=staff sgid=staff fsgid=staff tty=(none) ses=16 comm=sudo exe=/usr/bin/sudo subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(11/18/21 13:22:44.231:774) : avc: denied { signull } for pid=6748 comm=sudo scontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process permissive=0 I've never seen this before so it would be good to know when exactly it happens. Is any problem with commands execution logged to journal or insights logs?
> Is any problem with commands execution logged to journal or insights logs? None that are visible in the journal (see [2] above). If insights logs to someplace else than the journal, then (1) why oh why?, and (2) we don't capture this. As I cannot reproduce this, I can't grab other log files, sorry.
This hasn't happened anymore in our CI for the last 23 days. I think it only happened once, no?
As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter further, feel free to reopen this bug and attach the information needed for further troubleshooting.