Skip to content

Conversation

@yhabteab
Copy link
Member

@yhabteab yhabteab commented Nov 3, 2025

With the last security releases #10530 changed the logrotate config to use the icinga2 internal signal command to send the USR1 signal to the umbrella process, resulting rightfully in SELinux denials since this a confined executable. This PR allows the logrotate_t domain to be able to execute that bianry file. This might cause other SELinux deinials if the icinga2 internal command opens/reads some other Icinga 2 config files, but I'll test it tomorrow and share the results here.

time->Mon Nov  3 13:00:02 2025
type=PROCTITLE msg=audit(1762174802.598:899): proctitle=7368002D63000A09092F7573722F7362696E2F6963696E67613220696E7465726E616C207369676E616C202D2D7369672053494755535231202D2D70696420222428636174202F72756E2F6963696E6761322F6963696E6761322E70696420323E202F6465762F6E756C6C292220323E202F6465762F6E756C6C207C7C207472
type=SYSCALL msg=audit(1762174802.598:899): arch=c000003e syscall=21 success=no exit=-13 a0=56005035ab30 a1=4 a2=7ffc8efd9a40 a3=0 items=0 ppid=45588 pid=45591 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:logrotate_t:s0 key=(null)
type=AVC msg=audit(1762174802.598:899): avc:  denied  { read } for  pid=45591 comm="sh" name="icinga2" dev="sda4" ino=8532185 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:icinga2_exec_t:s0 tclass=file permissive=0
----
time->Mon Nov  3 14:00:00 2025
type=PROCTITLE msg=audit(1762178400.435:911): proctitle=7368002D63000A09092F7573722F7362696E2F6963696E67613220696E7465726E616C207369676E616C202D2D7369672053494755535231202D2D70696420222428636174202F72756E2F6963696E6761322F6963696E6761322E70696420323E202F6465762F6E756C6C292220323E202F6465762F6E756C6C207C7C207472
type=SYSCALL msg=audit(1762178400.435:911): arch=c000003e syscall=59 success=no exit=-13 a0=55e77ff91b30 a1=55e77ff914b0 a2=55e77ff8f690 a3=1b6 items=0 ppid=46418 pid=46421 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:logrotate_t:s0 key=(null)
type=AVC msg=audit(1762178400.435:911): avc:  denied  { open } for  pid=46421 comm="sh" path="/usr/sbin/icinga2" dev="sda4" ino=8532185 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:icinga2_exec_t:s0 tclass=file permissive=0

fixes #10616

@yhabteab yhabteab added the bug Something isn't working label Nov 3, 2025
@cla-bot cla-bot bot added the cla/signed label Nov 3, 2025
@yhabteab yhabteab added the backport-to-support/2.15 PRs with this label will automatically be backported to the v2.15 support branch. label Nov 4, 2025
@yhabteab yhabteab added this to the 2.16.0 milestone Nov 4, 2025
@yhabteab
Copy link
Member Author

yhabteab commented Nov 4, 2025

but I'll test it tomorrow and share the results here.

Tested, works fine and causes no other SELinux denials!

@Al2Klimov
Copy link
Member

Given su icinga icinga in our logrotate config and #10617, I'd just revert to /bin/kill. Dead simple. Neither additional policies, nor conditional rLimit needed. Just /bin/kill running under an unprivileged user, as previously.

@julianbrost
Copy link
Contributor

julianbrost commented Nov 4, 2025

Given su icinga icinga in our logrotate config

No, as already pointed out in #10527 (comment), that has no effect on postrotate (and other script commands).

Copy link
Contributor

@julianbrost julianbrost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks sane and also worked on my test machine.

@yhabteab yhabteab marked this pull request as draft November 20, 2025 11:19
@yhabteab
Copy link
Member Author

Please do not merge :). Would be nice if #10582 would be merged first, so that it can automatically backport it to the 2.15 support branch.

@julianbrost
Copy link
Contributor

Huh? That shouldn't be related to merging the original PR? Shouldn't it be possible to trigger a backport after the PR was merged?

@yhabteab
Copy link
Member Author

yhabteab commented Nov 20, 2025

Huh? That shouldn't be related to merging the original PR? Shouldn't it be possible to trigger a backport after the PR was merged?

Not at the moment. Currently it only supports the closed + merged event. That way it will instantly backport PRs after merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-to-support/2.15 PRs with this label will automatically be backported to the v2.15 support branch. bug Something isn't working cla/signed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SELinux is preventing sh from read access on the file /usr/sbin/icinga2 (logrotate)

4 participants