Dc add dns

[kmk3]

• disable-common.inc: split bind and knot tools
• disable-common.inc: blacklist missing bind tools
• disable-common.inc: blacklist missing knot tools
• disable-common.inc: blacklist unbound tools
• dnscrypt-proxy.profile: fix section structure
• disable-common.inc: add misc dns tools

[kmk3]

I'm unsure about the latest commit though; I don't know if these are used
elsewhere:

$ find etc -name '*dns*' | sort
etc/profile-a-l/dnscrypt-proxy.profile
etc/profile-a-l/dnsmasq.profile
etc/profile-a-l/fdns.profile

[reinerh]

are files like tsig-keygen and nsec3hash (and couple of others mentioned below) really used for communicating with DNS servers?
and are they commonly used? (at least I don't have them installed on my system)

i think the idea of the file is not to blacklist any binary in existence, but the ones commonly installed and where it makes sense to have them blacklisted.

what is your opinion @rusty-snake?

[kmk3]

+blacklist ${PATH}/nsupdate
+blacklist ${PATH}/rndc
+blacklist ${PATH}/rndc-confgen
+blacklist ${PATH}/tsig-keygen

are files like tsig-keygen and nsec3hash (and couple of others mentioned
below) really used for communicating with DNS servers?

Looking at the man pages for tsig-keygen / nsec3hash, they do look safe
indeed. But looking at the one for nsupdate, it is not obvious to me that it
cannot communicate with DNS servers.

Do you know which ones can be safely ignored? Should I try to come up with a
list?

and are they commonly used? (at least I don't have them installed on my
system)

Well, they are part of bind. I didn't have it installed prior to this PR
either. But if there exists a section for DNS tools, then wouldn't leaving it
incomplete give a false sense of security? Alternatively, how about moving the
section to a new disable-dns.inc? I had considered doing the latter, but I
thought that it would be a too invasive change for this PR. I can still do it
if it makes sense.

i think the idea of the file is not to blacklist any binary in existence, but
the ones commonly installed and where it makes sense to have them
blacklisted.

For reference, I just followed what was said on
#3810 (comment):

@glitsj16 commented 5 days ago

Would it be better to check each program or to merely
blacklist all binaries for safety/simplicity?

For now it might be a good idea to keep things simple and just add the
suggested binaries to disable-common.inc under the "# prevent DNS malware
attempting to communicate with the server..." section. We can always add
noblacklist ${PATH}/foo to relevant profiles later on. At first glance this
shouldn't break anything badly. But I'll do some more extended testing after
the weekend.

[glitsj16]

i think the idea of the file is not to blacklist any binary in existence, but the ones commonly installed and where it makes sense to have them blacklisted.

I fully agree. There seems to be a bit of a misunderstanding regarding my earlier comment. To be clear, I was only refering to khost, unbound-host and the dnssec-* tools from bind, nothing else. Whether or not we should have a dedicated disable-dns.inc is better left for a seperate discussion / PR IMHO. Apologies for the potential confusion.

[kmk3]

i think the idea of the file is not to blacklist any binary in existence,
but the ones commonly installed and where it makes sense to have them
blacklisted.

I fully agree. There seems to be a bit of a misunderstanding regarding my
earlier
comment.
To be clear, I was only refering to khost, unbound-host and the
dnssec-* tools from bind, nothing else. Whether or not we should have a
dedicated disable-dns.inc is better left for a seperate discussion / PR IMHO.
Apologies for the potential confusion.

Ah, I see now. When I read "the other executables mentioned on that Arch wiki"
I started looking at the packages and thought that the ones you mentioned were
only the most obvious examples that you noticed that were missing, not the full
list. I suppose I got carried away, sorry about that.

I have force-pushed adding only these 3 entries. Also, I'm not sure if ldnsd
can communicate with DNS servers. If not, should I remove it?