(Responses in-line) On 11/21/24 19:43, Gary wrote:
OK. I'll give it a shot.
Linux version 5.17.5-300.fc36.x86_64 (mockbuild@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 12.0.1 20220413 (Red Hat 12.0.1-0), GNU ld version 2.37-24.fc36) #1 SMP PREEMPT Thu Apr 28 15:51:30 UTC 2022
Can anyone else on-list confirm if Gary's running an up-to-date Fedora Core? Gary, have you tried whatever the update process is (maybe yum update or dnf update, I haven't run Fedora in several years so rusty on this point.) That's merely a stock suggestion. I know keeping those systems updated can be a chore, especially Fedora. All this rain is good system-updating weather.
Based on your request, I started looking around for something to send you. After a lot of scrolling around, I found this in the log:
2024-11-21T07:37:07.740484-08:00 Bastion audit[2514]: CRED_DISP pid=2514 uid=100 0 auid=1000 ses=24 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ms g='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/su" hostname=? add r=? terminal=/dev/pts/0 res=success' 2024-11-21T07:37:07.740855-08:00 Bastion audit[1717]: USER_LOGOUT pid=1717 uid=0 auid=1000 ses=24 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=logout id=1000 exe="/usr/sbin/lightdm" hostname=Bastion.mcg addr=? terminal=/dev/tty1 res=success' 2024-11-21T07:37:07.740970-08:00 Bastion ModemManager[645]: <info> caught signal, shutting down... 2024-11-21T07:37:07.741529-08:00 Bastion systemd[1]: Stopping session-24.scope - Session 24 of User gmcglinn... 2024-11-21T07:37:07.747574-08:00 Bastion audit[1717]: USER_END pid=1717 uid=0 auid=1000 ses=24 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring,pam_lastlog,pam_umask,pam_lastlog acct="gmcglinn" exe="/usr/sbin/lightdm" hostname=? addr=? terminal=:0 res=success'
So, you've got SELinux running. That's excellent, I'm a big fan. Wasn't, until I took a class at USENIX. Some SELinux items to consider: (1) "getenforce" command will indicate if SELinux is "off" (not the case here), "permissive", or "enforcing". Generally, if troubleshooting a stubborn problem, and only during the troubleshooting run, you can use "setenforce 0" to put SELinux into permissive mode, where it reports errors *as if* it was enforcing but then doesn't enforce. If flipping the system into permissive mode solves the observed problems, that's a smoking gun. But in general, leave the system in enforcing mode!
Use the "ausearch" command to find instances of SELinux enforcement where permission wasn't granted. I use this command to check:
sudo ausearch --interpret -ts this-month --success no
The man page has other useful values for -ts (time start) such as "recent". Typically you'll only care if the enforcement logs a failure: "res=failed". Fixing any indicated problems is mostly straightforward, let the list know if you find any SELinux issues.
Which has nothing to do with BPF. Since my original post, I have found instances in the log where BPF runs just fine. It looks like the shutdown occurred about 40 min before I noticed, and the interesting repeating BPF entries occur about 40 min after the shutdown.
2024-11-21T07:37:07.740970-08:00 Bastion ModemManager[645]: <info> caught signal, shutting down... ^^^^^^^^^^^^
This appears to be a normal daemon (ModemManager) shutting down in response to a signal (maybe SIGHUP or SIGTERM?). Nothing to see here, might be perfectly normal cycle for the daemon. Anyone else on-list more familiar with ModemManager who can confirm this? Maybe this is nightly maintenance cycle? Maybe driven by anightly cronjob (or the systemd equivalent?).
I'm a bit confused. The system had the monitor turned off and I was ssh'd into it from another system. It shouldn't have shutdown without me issuing an explicit shutdown request of some kind. But, it's old, and so it is probably just crufty.
But, since I was focused on BPF initially, I took a look at the logs for the system I was on (the remote system) and that's when I saw the interesting log entries:
Nov 18 00:00:01 entertain audit: BPF prog-id=470 op=LOAD Nov 18 00:00:01 entertain audit: BPF prog-id=470 op=UNLOADNov 18 00:00:01 entertain systemd[1]: Starting logrotate.service - Rotate log fi les... Nov 18 00:00:01 entertain systemd[1]: unbound-anchor.service: Deactivated succes sfully. Nov 18 00:00:01 entertain systemd[1]: Finished unbound-anchor.service - update o f the root trust anchor for DNSSEC validation in unbound. Nov 18 00:00:01 entertain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 se s=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=unbound-anchor comm="sys temd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 18 00:00:01 entertain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses =4294967295 subj=system_u:system_r:init_t:s0 msg='unit=unbound-anchor comm="syst emd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 18 00:00:01 entertain systemd[1]: logrotate.service: Deactivated successfull y. Nov 18 00:00:01 entertain systemd[1]: Finished logrotate.service - Rotate log fi les. Nov 18 00:00:01 entertain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 se s=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=logrotate comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 18 00:00:01 entertain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses =4294967295 subj=system_u:system_r:init_t:s0 msg='unit=logrotate comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 18 00:00:01 entertain audit: BPF prog-id=470 op=UNLOAD
Every day.
I think the first and last lines are all that matter. The intervening entries aren't consistent from day to day. Since the Wikipedia page for BPF states that the Chinese alledge that the NSA uses BPF to hide packets, I found this pattern interesting. Maybe somebody else is too. It could be just harmless firewall stuff.
This looks exactly like what I would expect for a daily logrotate process. Stop the daemon, rotate the log, start the daemon. You might garner more info with something like:
systemctl list-unit-files | egrep 'log|rotate'
There may even be a man page for logrotate.service?
But, the BPF stuff and the Spectre virus (somehow related to BPF per Wikipedia) seemed interesting, so I thought I would find out more about them, starting with BPF.
So, I don't think BPF harms my system, but it may provide that capability to someone else.
Not that I'm paranoid LOL.
"I believe that the moment is near when by a procedure of active paranoiac thought, it will be possible to systematize confusion and contribute to the total discrediting of the world of reality." -- Salvador Dali