This is the interpreted audit record:
----
type=PROCTITLE msg=audit(08/23/21 17:16:03.107:43895) : proctitle=/usr/sbin/keepalived --dont-fork -D
type=AVC msg=audit(08/23/21 17:16:03.107:43895) : avc:  denied  { setattr } for  pid=320024 comm=keepalived name=bypass_ipvs.sh dev="dm-0" ino=5146028 scontext=system_u:system_r:keepalived_t:s0 tcontext=system_u:object_r:keepalived_unconfined_script_exec_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(08/23/21 17:16:03.107:43895) : arch=x86_64 syscall=utimensat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x557a0a815fa0 a2=0x7ffd0057fab0 a3=0x0 items=0 ppid=320022 pid=320024 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=keepalived exe=/usr/sbin/keepalived subj=system_u:system_r:keepalived_t:s0 key=(null)
----

Brandon, keepalived seems to call utimensat() to the script - is this expected behaviour?

Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: (Line 54) Unknown ke>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: NOTICE: setting conf>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: Starting Healthcheck>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: Starting VRRP child >
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com systemd[1]: keepalived.service: Failed w>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com systemd[1]: keepalived.service: Unit pro>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com systemd[1]: Failed to start LVS and VRRP>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: pid 124891 exited wi>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: CPU usage (self/chil>
Sep 02 03:24:14 kvm-07-guest07.hv2.lab.eng.bos.redhat.com Keepalived[124890]: Stopped Keepalived v>
beaker-rhel9#

beaker-rhel9# rpm -q keepalived
keepalived-2.2.4-1.el9.x86_64

I haven't been able to figure out where this syscall is coming from.  The script (which is attached) really doesn't do anything other than calling iptables.  I went through the keepalived and iptables source code and can find no use of utimensat().  This same script has been used in RHEL 6, 7, and 8 with no issues.   The script really hasn't changed since 2008.  Not exactly sure what else to look at.

PR:https://github.com/fedora-selinux/selinux-policy/pull/910

Brandon,

Do you know why keepalived calls utimensat() on the executable which is on the line with the notify keyword? It is not allowed and we cannot allow it for all commands.

    notify /usr/bin/netstat-apn

----
type=PROCTITLE msg=audit(01/05/2022 11:22:50.465:511) : proctitle=/usr/sbin/keepalived --dont-fork -D --snmp
type=PATH msg=audit(01/05/2022 11:22:50.465:511) : item=0 name=/usr/bin/netstat-apn inode=4215811 dev=fd:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(01/05/2022 11:22:50.465:511) : cwd=/
type=SYSCALL msg=audit(01/05/2022 11:22:50.465:511) : arch=x86_64 syscall=utimensat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x557218e7d8a0 a2=0x7ffcedfad040 a3=0x0 items=1 ppid=31334 pid=31336 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=keepalived exe=/usr/sbin/keepalived subj=system_u:system_r:keepalived_t:s0 key=(null)
type=AVC msg=audit(01/05/2022 11:22:50.465:511) : avc:  denied  { setattr } for  pid=31336 comm=keepalived name=netstat-apn dev="vda1" ino=4215811 scontext=system_u:system_r:keepalived_t:s0 tcontext=unconfined_u:object_r:bin_t:s0 tclass=file permissive=0

The actual problem is that keepalived calls utimensat() on *any* executable on the line with the notify keyword, even from /usr/libexec/keepalived with the correct selinux label. We'd like to know if there is any reason for that.


----
type=PROCTITLE msg=audit(01/11/2022 10:03:14.533:529) : proctitle=/usr/sbin/keepalived --dont-fork -D
type=PATH msg=audit(01/11/2022 10:03:14.533:529) : item=0 name=/usr/libexec/keepalived/bypass_ipvs.sh inode=33554649 dev=fd:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:keepalived_unconfined_script_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(01/11/2022 10:03:14.533:529) : cwd=/
type=SYSCALL msg=audit(01/11/2022 10:03:14.533:529) : arch=x86_64 syscall=utimensat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x55a5ac0e1c60 a2=0x7ffe17fabbf0 a3=0x0 items=1 ppid=37521 pid=37523 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=keepalived exe=/usr/sbin/keepalived subj=system_u:system_r:keepalived_t:s0 key=(null)
type=AVC msg=audit(01/11/2022 10:03:14.533:529) : avc:  denied  { setattr } for  pid=37523 comm=keepalived name=bypass_ipvs.sh dev="vda1" ino=33554649 scontext=system_u:system_r:keepalived_t:s0 tcontext=unconfined_u:object_r:keepalived_unconfined_script_exec_t:s0 tclass=file permissive=0

Ryan, Brandon,

Have you managed to make any progress in finding out why keepalived would call utimensat()?

Retargetting to 9.1.

*** Bug 2049409 has been marked as a duplicate of this bug. ***

Ryan,

Did you manage to find any clue in this issue?

Switching the component for further troubleshooting.

keepalived scripts executed from the /usr/libexec/keepalived/ directory run in the keepalived_unconfined_script_t SELinux domain.
This bz was open to report a setattr SELinux denial, but it turned out the keepalived daemon calls utimensat() on the script file.

The following steps can be done to get a full backtrace of the AVC denial event:

 # dnf install perf
 # perf record -o perf.data -a -g --call-graph dwarf -e avc:selinux_audited -- /path/command
 # perf script -i perf.data

See also:
https://www.paul-moore.com/blog/d/2020/12/linux_v510.html

I circled back to take a look at this for 9.2, but I never found where keepalived is calling utimensat(). A quick grep through the source code reveals nothing, so I'm assuming that it is being called indirectly. I am taking a second look.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Github user szarkos has identified where utimensat() is being called; the details are at https://github.com/acassen/keepalived/issues/2333.

magic_open() called with flag MAGIC_PRESERVE_ATIME calls utimes() in function close_and_restore() in src/magic.c in the file source code (see https://github.com/file/file/blob/master/src/magic.c#L371). utimes() in glibc calls utimensat().

Upstream commit b2b6539 removes MAGIC_PRESERVE_ATIME and so utimensat() should no longer be called.