dnscrypt-proxy VS sbctl

There is more than one way to do this but I have decided to use dnscrypt-proxy. We will not be using dnscrypt for the dnscrypt protocol though you could elect to use that as the underlying DNS protocol. dnscrypt-proxy lets's us use a SOCKS5 proxy through which the DNS queries will be sent. We will use a Tor SOCKS5 proxy here. You can choose which protocols should be enabled and which ones should be disabled. There are two points:

I tried installing the RPM from the Fedora repos but it's out-of-date and there were no instructions on how to get it operational, so I went with the manual approach as per their wiki: https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-linux

This is awesome, thanks -- going to look into that now. I found SmartDNS interesting and thought I would share it, it's pretty simple to setup. I can see why it's Chinese focused, they have "interesting" internet access over there :-).

I have been looking into DNS quite a bit lately (Unbound, etc), as DNS lookup performance has been pretty subpar lately. I'm in Perth, Australia, and we're pretty remote so our latency is meh at best, and Cloudflare performance has been all over the shop lately, I think they're having issues in WA). DNS can also cause really routing issues here sometimes as we get better latency to Singapore than Sydney, so we might get shunted off to SG.

I've also been using dnscrypt-proxy2 (https://github.com/DNSCrypt/dnscrypt-proxy) for a while, but the above issues with Cloudflares DNS is what triggered me to look into other options.

I use a min-cache-ttl of 15 minutes, which seems to work well.

Thank you for sharing this tip about, looking into this now :).

Sure. I run dnscrypt_proxy behind a pihole. https://github.com/DNSCrypt/dnscrypt-proxy

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

No problem! The sbctl package ships with a pretty extensive hook out of the box (https://github.com/Foxboron/sbctl/blob/master/contrib/pacman/ZZ-sbctl.hook). It's been very reliable for automatically resigning .efi executables after updates for me.

sbctl verify returns failed to find EFI system partition despite it definitely is there. It's the same issue as this but remounting or restarting doesn't fix it.

lol

Must actually prevent unsigned images from booting

sudo dnf install asciidoc golang -y VERSION=0.11 cd /tmp curl -L "https://github.com/Foxboron/sbctl/releases/download/${VERSION}/sbctl-${VERSION}.tar.gz" | tar zxvf - cd "sbctl-${VERSION}" make sudo make install cd ~

By far the easiest is to use sbctl to generate, install and use keys to sign your efi images. You can use mkinitcpio to build the unified kernels automatically and a pacman trigger to rerun the sbctl signing when the kernel is updated. Pretty straightforward (once you've done it once).

The question is whether you have any UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.

If you're using a TPM for Secure Boot, you can use the command in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.