Dear Maintainer,
In summary, needrestart seemingly doesn't display any output when SELinux is set to Enforcing mode on Debian running the "default" policy (as listed by sestatus / as provided by selinux-policy-default), insofar as returning zero output when run on the VM console (I wasn't sure if screenshots were considered polite so I've omitted it for the time being).
However, it does seemingly run orrectly when run from an ssh session on the same machine:
root@debtestbug0:~# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: default
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
root@debtestbug0:~# needrestart
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
debconf: DbDriver "templatedb": could not write /var/cache/debconf/templates.dat-new: Permission denied
(It working under an ssh session was only spotted when I was already preparing this bug report via a test VM, since the key systems I spotted the original problem on are airgapped and only have virtual console access)
At first I thought this was merely a type enforcement problem, since denied AVCs for needrestart_t do indeed show up in /var/log/auditd/audit.log; I got as far as creating a custom TE (attachment test_needrestart.te) and policy based on all of the AVC denials I could see relating to needrestart in the audit logs, but after applying it there was still no output on the console.
The background here is there's been a big push for enhanced security on a number of systems, many of which are air-gapped and inaccessible via ssh, where it looks like needrestart doesn't return output correctly and I can't really figure out why. But obviously it's a key tool for operators on the lookout for boxes that might not have been rebooted in to new kernels or had their daemons restarted for whatever reason.
Systems here are all up-to-date Trixie installs so no oddities I'm aware of in the packages (other than the obvious eccentricity of running SELinux on Debian) running on VMware ESX virtual machines.
I wasn't sure whether this needed to be handled by the needrestart maintainers themselves but figured filing directly against needrestart was the best place to start; given that this seemingly only affects the console (something that wasn't evident until I stood up a test VM in a non-airgapped environment to confirm) it's possible it's down to a problem with the SELinux policy for open-vm-tools (which does have a large number of policy violations in the denied AVCs already, but none that seemingly affect its normal running operations) but just supposition at this point.
More details available on request of course but I figure this report is probably already a bit too wordy and didn't want to flood it with a lot stuff in e.g. AVC denies unless it was asked for. But if anyone's got any pointers on where I can start looking or requests for additional info I'm happy to oblige where possible.
Hopefully the formatting of this mail is up to snuff, I'm unable to use reportbug directly.
-------------------------------
G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action.
The information in this email is intended only for the named recipient. If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure. For information about how G-RESEARCH uses your personal data, please refer to our Privacy Policy.
G-RESEARCH is the trading name of Alastair LLP and its affiliates globally. Alastair LLP is a limited liability partnership registered in England with number OC451515 and registered office 8th Floor One Soho Place, London, W1D 3BG.