Solved: Updated from f37 to f38: Problems with SELinux

jrredho · April 28, 2023, 2:07am

Wow! I just upgraded to f38 from f37, and I’m getting hundreds of selinux-related audit reports.

The vast majority of them are coming from read requests by ‘systemd-resolved’ for the file /etc/resolv.conf, although some of them are from vpn-related command requests to that same file.

I following the advice in the system-update documentation on cleaning up after the dnf system-update reboot and executed sudo fixfiles -B onboot and re-booted. That did not fix things with selinux for me.

Am I the only one experiencing this?!

Thanks!

ilikelinux · April 28, 2023, 3:16am

sudo touch /.autorelabel and then restart the system.
This should force to relabel the selinux labels.

You can check this while pressing Esc on the boot process.

jrredho · April 28, 2023, 3:42am

Thanks so much for your quick response to my question! Unfortunately, I’m still in the same state after running your recommended command. It did relabel on re-boot, then automagically rebooted.

My notifications are strobing, faster than a blink of an eye, hundreds of times, with SELinux security alerts on this. Here’s a typical one:

Source Context                system_u:system_r:systemd_resolved_t:s0
Target Context                system_u:object_r:NetworkManager_etc_rw_t:s0
Target Objects                /etc/resolv.conf [ lnk_file ]
Source                        systemd-resolve
Source Path                   /usr/lib/systemd/systemd-resolved
Port                          <Unknown>
Host                          jrredho-lt3
Source RPM Packages           systemd-resolved-253.2-1.fc38.x86_64
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.11-1.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.11-1.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     jrredho-lt3
Platform                      Linux jrredho-lt3 6.2.12-300.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Thu Apr 20 23:05:25 UTC 2023
                              x86_64
Alert Count                   49
First Seen                    2023-04-27 21:27:28 MDT
Last Seen                     2023-04-27 21:27:44 MDT

It makes sense since the source and target contexts are in disagreement. It is very disquieting.

Thanks for any further suggestions!

vgaetera · April 28, 2023, 4:14am

Try this:

sudo restorecon -R -F /etc

If the issue persists, check the output:

journalctl --no-pager -b -g avc
ls -l -Z /etc/resolv.conf

jrredho · April 28, 2023, 5:33am

Thanks to you, too, Vladislav, for your suggestion!

Still no love from my laptop, though. I had no idea before this just how often DNS queries are made!

The results from both the journalctl and ls commands are consistent with what I listed in the snippet I copied in my OP, although, there is an inconsistency between the symbolic link’s permissions:

jrredho@jrredho-lt3:~/Downloads$ ls -l -Z /etc/resolv.conf
lrwxrwxrwx. 1 root root system_u:object_r:NetworkManager_etc_rw_t:s0 39 Jul 16  2022 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

and what the SELinux context is for what the symbolic link points to:

jrredho@jrredho-lt3:~/Downloads$ ls -l -Z /run/systemd/resolve/stub-resolv.conf
-rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 920 Apr 27 23:05 /run/systemd/resolve/stub-resolv.conf

But I’m getting strobed with notifications to the point where I feel like I’m risking getting hypnotized by them. Hypnotized or not, I’m definitely confused.

Thanks everyone!

vekruse · April 28, 2023, 6:29am

The SElinux type should be net_conf_t.

ls -lZ /etc/resolv.conf
-rw-r--r--. 1 root root unconfined_u:object_r:net_conf_t:s0 19 Feb 17 23:28 /etc/resolv.conf

This would normally be a symbolic link and not a regular file.

Try to run

rm /etc/resolv.conf
ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

and see if that fixes it. I not, you may have some customized SElinux rules.

jrredho · April 28, 2023, 4:15pm

Hey Villy, thanks for this suggestion! And, yep, it did work.

I do have the continual problem that upon reboot, this link gets recreated with the original context that I showed earlier. I’m using Mullvad VPN application, which might be the culprit. I’ll work to track that down from here…

Thanks again, everyone, for your kind attention to my little issue!

jrredho · April 28, 2023, 8:47pm

Welp, I’ve done just a little bit of digging in my system log, and I see at boot time the following:

Apr 28 14:31:20 jrredho-lt3 audit[1297]: AVC avc:  denied  { read } for  pid=1297 comm="systemd-resolve" name="resolv.conf" dev="dm-0" ino=8954682 scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:NetworkManager_etc_rw_t:s0 tclass=lnk_file permissive=0
Apr 28 14:31:20 jrredho-lt3 audit[1297]: SYSCALL arch=c000003e syscall=262 success=no exit=-13 a0=ffffff9c a1=55ed05f4de70 a2=7ffebf4d0f60 a3=0 items=1 ppid=1 pid=1297 auid=4294967295 uid=193 gid=193 euid=193 suid=193 fsuid=193 egid=193 sgid=193 fsgid=193 tty=(none) ses=4294967295 comm="systemd-resolve" exe="/usr/lib/systemd/systemd-resolved" subj=system_u:system_r:systemd_resolved_t:s0 key=(null)
Apr 28 14:31:20 jrredho-lt3 audit: CWD cwd="/"
Apr 28 14:31:20 jrredho-lt3 audit: PATH item=0 name="/etc/resolv.conf" nametype=UNKNOWN cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
Apr 28 14:31:20 jrredho-lt3 audit: PROCTITLE proctitle="/usr/lib/systemd/systemd-resolved"
Apr 28 14:31:20 jrredho-lt3 systemd-resolved[1297]: Failed to stat /etc/resolv.conf: Permission denied
Apr 28 14:31:20 jrredho-lt3 systemd[1]: Started systemd-resolved.service - Network Name Resolution.

This is telling me that before the systemd-resolved service is started, NetworkManager has already removed, then relinked /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf. When it does this relinking the link is given SELinux context system_u:object_r:NetworkManager_etc_rw_t:s0.

I believe that the above is the root of all of my troubles. Can anyone suggest how I might take this further towards a resolution?

Thanks!

jrredho · April 28, 2023, 9:43pm

My apologies for this long winded thread for which the OP is a naive actor, to say the least. Now I finally think I have this sorted out.

I re-booted my machine, then did the remove and re-symbolic link thing suggested above.

Then I did the following:

When I re-checked my the context for /etc/resolv.conf, it was back to

I think that this means there is an SELinux context for /etc/resolv.conf that is incorrectly defined in the current policy. Is there a way for me to correct this manually on my system?

Thanks again.

vekruse · April 28, 2023, 10:27pm

It is more a question of what customizations has been done in the past. Or if Mullvad has installed some SELinux rules incompatible with Fedoras SELinux configurations. This will be hard to diagnose remotely; it all depends on the history of the system all the way back to the first installation.

jrredho · April 28, 2023, 11:03pm

I don’t doubt this for a second! It does seem odd to me that the context for /etc/resolv.conf is identical to that of the directory /etc/NetworkManager.

For the time being, I have a support question in with Mullvad on this. I will report back if I learn more.

Thanks again, this has been very educational.

Cheers!

computersavvy · April 28, 2023, 11:21pm

One test to confirm if Mullvad is the cause would be to disable Mullvad, reset the link as you have done previously so it works, then reboot. See if the context remains proper.

Then enable Mullvad and see if the context changes.

This is just one possible way to confirm that Mullvad may be the cause of the problem.

vekruse · April 29, 2023, 7:03am

There is a set of files which controls that. Try

 grep -r resolv  /etc/selinux/targeted/contexts/files/

It would normally contain

/etc/selinux/targeted/contexts/files/file_contexts:/etc/\.resolv\.conf.*	--	system_u:object_r:net_conf_t:s0

which is the entry which controls restorecon to set the right SElinux attributes.

vekruse · April 29, 2023, 9:02am

There is a SElinux gui tools you might try out. It is in the package policycoreutils-gui and you can run it as system-config-selinux.

vgaetera · April 29, 2023, 12:09pm

FYI, restoring SELinux context certainly works even with Mullvad VPN installed:

> rpm -q mullvad-vpn 
mullvad-vpn-2023.3-1.x86_64

> sudo chcon -h system_u:object_r:NetworkManager_etc_rw_t:s0 /etc/resolv.conf

> ls -Z /etc/resolv.conf
system_u:object_r:NetworkManager_etc_rw_t:s0 /etc/resolv.conf

> sudo semanage fcontext -l | grep -e "/etc/resolv.*conf"
/etc/resolv-secure.conf.*                          regular file       system_u:object_r:net_conf_t:s0 
/etc/resolv\.conf.*                                all files          system_u:object_r:net_conf_t:s0

> sudo restorecon -R -F /etc

> ls -Z /etc/resolv.conf
system_u:object_r:net_conf_t:s0 /etc/resolv.conf

jrredho · April 29, 2023, 5:04pm

Hey Guys,

Thanks for hanging with me on this! Yet still more questions…

Villy Kruse:

grep -r resolv /etc/selinux/targeted/contexts/files/

It would normally contain
/etc/selinux/targeted/contexts/files/file_contexts:/etc/\.resolv\.conf.*	--	system_u:object_r:net_conf_t:s0

II’m guessing this is telling me that these matches are regular expressions. Regardless, I get:

/etc/selinux/targeted/contexts/files/file_contexts:/etc/resolv\.conf.*	system_u:object_r:net_conf_t:s0

but further down, I also get this:

/etc/selinux/targeted/contexts/files/file_contexts.local:/etc/resolv.conf    system_u:object_r:NetworkManager_etc_rw_t:s0

which explains my situation.

So it seems that the match in the file_contexts regexp is being overridden by the explicit match in file_contexts.local, or that the fact it’s in that latter file is the reason regardless of it being an explicit match. Maybe one of my other VPN applications has created this situation. (Confession: I also had ProtonVPN installed for the first round of dnf system-upgrade...; I removed it prior to the second round with --setopt=keepcache=1.)

If I cat filecontexts.local, I see the following:

# This file is auto-generated by libsemanage
# Do not edit directly.

/usr/lib/chromium-browser    system_u:object_r:bin_t:s0
/usr/lib/chromium-browser/chromium-browser.sh    system_u:object_r:bin_t:s0
/usr/lib/chrome-sandbox    system_u:object_r:chrome_sandbox_exec_t:s0
/var/cache/Canon/CUPS_SFPR    system_u:object_r:cupsd_var_run_t:s0
/etc/resolv.conf    system_u:object_r:NetworkManager_etc_rw_t:s0

However I got to this point is a complete mystery.

Okay, on to the next mystery in my little epic…

I’m a little confused by this one. Would this not change the context to what I already have in file_contexts.local? Is there a way to remove this latter entry all together?

Many, many thanks, again, for your help!

vekruse · April 29, 2023, 5:25pm

That is exactly what is happening, and what I suspected was the case. file_contexts.local is your local modifications of the SELinux rules and will override the Fedora provided rules. You should be able to use the system-config-selinux tool to remove that entry and that should solve your problem.

vgaetera · April 29, 2023, 5:48pm

That command is just for testing, you can ignore it.

sudo semanage fcontext -d -t NetworkManager_etc_rw_t /etc/resolv.conf

jrredho · April 29, 2023, 6:23pm

Done!

Thanks so much to you both for all of the help. This was far, far more educational than just merely fixing this crazy situation that I’ve managed to get myself into.

Cheers!