When running $ ujust dns-selector, the command will fail with exit code 1, and the same happens when attempting to restart the service for some reason, but everything works just fine if I $ setenforce 0 and $ setenforce 1 again after setting up DNS (it doesn't persist on reboot though and I'd have to disable and reenable enforcement again just to have a working network at all). BTW the image i'm using is silverblue-main-hardened:latest on version 42.20250920.0
#SElinux is keeping dnsconfd.service from starting
1 messages · Page 1 of 1 (latest)
@elder umbra ?
hey, is there anything unusual about your setup at all?
e.g. have you modified anything in /etc/dnsconfd.conf or /etc/unbound/*?
usually this would mean something has the wrong type, so you'd need to restorecon -R -F <whatever directory>
no, i haven't
i don't think so, other than maybe having rebased from silverblue, it seems pretty standard
as root, after the denial happens, could you try ausearch -m avc -ts recent | fpaste?
that was my next question lol
oh okay
it should dump any recent denials into a pastebin
alternatively, could you just share a portion of the AVCs?
i'm going to try to recreate this by rebasing from silverblue to secureblue
you mean after failing to setup dns?
or is it something else
yeah, so at the point you would usually setenforce 0, i'd like to see the output of ausearch -m avc -ts recent
just to see what the exact SELinux denial is
if it's not producing output, you could try sharing the entire relevant log:
grep AVC /var/log/audit/audit.log
# or, to dump to pastebin:
grep AVC /var/log/audit/audit.log | fpaste
alternatively, it could not be SELinux at all, and maybe the setenforce 0 succeeding was just a red herring
could I see the output of stat /run/unbound/anchor-disable? @pliant quiver
sure, hold on
thank youu
that's... as expected
so as far as i can see, this is the relevant AVC
type=AVC: avc: denied { setattr } for comm="(dnsconfd)" name="anchor-disable" dev="tmpfs" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:named_var_run_t:s0 tclass=file permissive=0
could you, as root, run systemctl edit unbound.service and paste this:
[Service]
RuntimeDirectory=
RuntimeDirectoryMode=
RuntimeDirectoryPreserve=
and see if that resolves your issue? @pliant quiver
sorry about this, i'm not sure why it'd be different on a rebased system
have you ever installed unbound or dnsconfd in the past?
no, but i did try using dnscrypt-proxy and also dnsmasq because resolved was breaking some things
Noooo why did you admit that. Now you're no longer entitled to compensation!!!1
well, hopefully you'll feel comforted by the fact that resolved isn't causing issues anymore!
it's SELinux now :(
unbound seems to be working pretty good though, if i bypass this issue with selinux that is
init_t wants setattr on named_var_run_t
specifically, it seems, /run/unbound/anchor-disable
but why
go join the systemd people
maybe you'll finally be the one who fixes their DNSSEC implementation
even with DNSSEC disable it would break things
How DARE you. I've never fixed anything in my entire life! Don't you insinuate I'd ever do something like that!
like youtube straight up wouldn't load for some reason and that would force me to use the browser dns
there's a minecraft bedrock launcher that also wouldn't work
it's funny, rhel doesn't include resolved, despite fedora being its upstream
no idea what was going on there and tbh i'd rather not know 🥸
there's no way enterprise customers are going to want to deal with systemd-resolved's bullshit
so, in trying to reproduce your issue:
- run f42 silverblue
- install/start and stop/uninstall dnsmasq and dnscrypt-proxy
- rebase to secureblue
gimme a min
it seems like it's just not saving my changes 😕
oh? 😵💫
so you do systemctl edit unbound.service, paste in the patch, it doesn't produce an error message... but when you do systemctl edit unbound.service again, the patch has disappeared? @pliant quiver
and you're entering this?
[Service]
RuntimeDirectory=
RuntimeDirectoryMode=
RuntimeDirectoryPreserve=
idk if i've done smth wrong here but i don't think so
ohh
no just paste them in at the top
see ## Edits below this comment will be discarded
### Anything between here and the comment below will become the contents...
dw
👍
it didn't work

ugh i can't repro by rebasing from silverblue
ah
can i see ls -Z /usr/bin/dnsconfd @pliant quiver ?
system_u:object_r:dnsconfd_exec_t:s0
couldn't send ss cause I'm on my phone
that's fine :(
cause i don't to deactivate selinux on my laptop so it's easier to test things
maybe you should take some rest, i feel like this can be quite maddening
thank you
ah apologies, ik this is getting tiresome
i'm interested in why you're getting an SELinux failure like this though
you probably won't be the only one, it's a recent change
if you have a chance, you could add [Service] SELinuxContext=system_u:system_r:dnsconfd_t:s0 to systemctl edit dnsconfd.service
note it's dnsconfd you'd be editing, not unbound
done
can't restart the service though
i don't know but that's not new
if i systemctl restart dnsconfd.service it just fails
it wasnt failing before
the idea with the SELinuxContext line is that we force the running context of dnsconfd.service to dnsconfd_t
if it fails to start with setenforce 0 now, that means it's unable to be in the right context
oh actually maybe setenforce 0 would allow running it in a weird context too
the simple nuclear option might be:
run0
rm -rf /run/unbound
mkdir /run/unbound
chmod 0775 /run/unbound
chown unbound:unbound /run/unbound
if that doesn't work, i'll go away and try harder to reproduce this
maybe someone else will have an idea
should i revert the changes to dnsconfd.service and unbound.service?
sure :)
it didn't work either
when you get dnsconfd/unbound running with setenforce 0, what's the output of ps -eZ | grep -e dnsconfd -e unbound?
again, sorry about this
i'm going to try to reproduce it so i don't have to keep bugging you >:)
oh dw abt that
it's totally fine with me since i'm not really doing any of the work myself lol
Solved?
nope
😕
yeah, i'm trying to reproduce it :(
i can't help but feel this is down to the systemd RuntimeDirectory setting
it is redundant, and it does explain why init_t would be trying to set attributes on named_var_run_t
it's difficult to figure out what's going on because it's in /usr
i think, in general, all of secureblue's systemd overrides should perhaps go in /etc, we don't have a consistent policy
there are timer overrides in /etc under override.conf, service overrides in /usr under both override.conf and secureblue.conf... it's a bit of a mess
Can I test something?
the AVC is related to systemd trying to access config files? and why is this unique to a single user?
it is, it seems systemd is trying to setattr /run/unbound/anchor-disable
likely related to
RuntimeDirectory=unbound
RuntimeDirectoryMode=0775
RuntimeDirectoryPreserve=yes
which is actually redundant anyway, because tmpfiles creates with these perms already
as to why it's only affecting this user? i have no idea, but they've previously installed dnsmasq/proxy before they rebased (ironically, due to issues with systemd-resolved)
was @pliant quiver already using unbound
nope
very odd
i wasn't
i did try dnscrypt-proxy and dnsmasq but i didn't stick to them so i was o resolved before i updated my system
is there a workaround? manually restorecon I assume?
i think it's worth noting that i did use the testing image as an attempt to get rid of resolved for good, and that was my actual first time with unbound, but i experienced the same error and just rolled back at the time
my guess was that something's subtly wrong with the DAC on /var/lib/unbound or /run/unbound that's causing systemd/init_t to try to setattr them
which policy won't allow
the workaround i've been using is to just disable selinux and reenable it after getting unbound up and running
chown -R unbound:unbound /run/unbound
restorecon -R -F /run/unbound
chown -R unbound:unbound /var/lib/unbound
restorecon -R -F /var/lib/unbound
@pliant quiver this should do it
it worked🎉
oh thank god
i'll just reboot and see if it persists
uh one sec
sorry, if you haven't already
what's the contents of /etc/tmpfiles.d/unbound.conf?
it should be D /run/unbound 0755 unbound unbound -
if it's not, you might have had unbound installed already
actually, that's another thing that should be in /usr, not /etc
uhh
it didn't btw
if i reboot i get the same problem again
oh, that's unusual
secureblue ships a file in that location, for sure
(as root) ```cp /usr/etc/tmpfiles.d/unbound.conf /etc/tmpfiles.d/unbound.conf
chmod 0644 /etc/tmpfiles.d/unbound.conf
the /etc/tmpfiles.d dir doesn't exist on my system
it doest exist on /usr/etc though
How dare you waking me, I just fell asleep
Kidding, I don't sleep
do you have a directory at /etc/tmpfiles.d? and a file at /etc/tmpfiles.d/unbound.conf? and also at /usr/etc/tmpfiles.d
I s2idle
Let me check
i definitely s2idle
oh no! i'm sorry
i saw a green circle next to your name
oh so you do have something at /usr/etc/tmpfiles.d/unbound.conf?
yeah
oh i must have misinterpreted
thank you!
i didn't notice the typo, my bad
ok @pliant quiver i think your issue should be fixed
At etc/tmpfiles.d/:
chrony.conf unbound.conf
I have 2 files at /etc/tmpfiles.d chrony and unbound, at /usr/etc/tmpfiles.d i also have them the same files
cat /etc/tmpfiles.d/unbound.conf returns D /run/unbound 0755 unbound unbound -
ok thanks
lmk if it's still not working?
ls /usr/etc/tmpfiles.d/ returns:
chrony.conf unbound.conf
it worked for real this time!
Naa all good, I' awake
thanks for your help

