-
Bug
-
Resolution: Won't Do
-
Minor
-
rhel-8.9.0
-
None
-
rhel-sst-security-selinux
-
ssg_security
-
None
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
None
What were you trying to do that didn't work?
When a service is of type "Notify" and its startup script executes systemd-notify to tell systemd it's ready, the following AVC pop up:
type=PROCTITLE msg=audit(02/15/2024 10:55:23.848:260) : proctitle=systemd-notify --ready type=SYSCALL msg=audit(02/15/2024 10:55:23.848:260) : arch=x86_64 syscall=sendmsg success=no exit=EPERM(Operation not permitted) a0=0x3 a1=0x7fff3972ed90 a2=MSG_NOSIGNAL a3=0x7fff3972ed14 items=0 ppid=25967 pid=25969 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-notify exe=/usr/bin/systemd-notify subj=system_u:system_r:systemd_notify_t:s0 key=(null) type=AVC msg=audit(02/15/2024 10:55:23.848:260) : avc: denied { sys_admin } for pid=25969 comm=systemd-notify capability=sys_admin scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:system_r:systemd_notify_t:s0 tclass=capability permissive=0
This is a continuation of RHEL-25605 .
The reason is unclear to me, we can see in systemd-notify code that a first attempt to send the message with "fake credentials" is performed, which fails, then tried again, which is then a success:
437 _public_ int sd_pid_notify_with_fds( 438 pid_t pid, 439 int unset_environment, 440 const char *state, 441 const int *fds, 442 unsigned n_fds) { : 525 /* First try with fake ucred data, as requested */ 526 if (sendmsg(fd, &msghdr, MSG_NOSIGNAL) >= 0) { 527 r = 1; 528 goto finish; 529 } 530 531 /* If that failed, try with our own ucred instead */ 532 if (send_ucred) { 533 msghdr.msg_controllen -= CMSG_SPACE(sizeof(struct ucred)); 534 if (msghdr.msg_controllen == 0) 535 msghdr.msg_control = NULL; 536 537 if (sendmsg(fd, &msghdr, MSG_NOSIGNAL) >= 0) { 538 r = 1; 539 goto finish; 540 } 541 } :
The AVC pops up on line 526.
It's unclear to me whether systemd code has to be fixed or if SYS_ADMIN should be granted, I believe it should be harmless to grant SYS_ADMIN to systemd_notify_t type.
Please provide the package NVR for which bug is seen:
selinux-policy
How reproducible:
Always
Steps to reproduce
Create /etc/systemd/system/repro.service with content below
[Service]
Type=notify
NotifyAccess=all
ExecStart=/bin/sh -c "sleep 3; systemd-notify --ready; sleep 30"
Reload systemd and start the service
- systemctl daemon-reload
- systemctl start repro
Expected results
No failure
Actual results
AVC
- is cloned by
-
-
- Closed
-
