OSI-Auflauf

This can be boiled down to half a page. Why put in the chatgpt manure to.inflate it.

Ugh so much inflated text and self congratulation to something that in the end boils down to trusting you as authority again.

Don't waste your time with dns adblocking.

If you are serious about network side blocking do tls interception (lmao) but that is a lot of maintenance, adds other attack surface and the average openwrt device isn't beefy enough for such things.

Firefox and Ublock Origin against ads.

There is cooler stuff for Openwrt. Mesh nets between friends, to share internal services. Just tinkering with and learning about network stuff. Adding ipv6 to tunnel if isp doesn't support. Having Wifi whose autochannel doesn't suck.

Dual Antennas -> Sword fighting. Only fun with multiple devices and dabbling with mesh mode or throughput maxing. In ax dual channel 40mhz +160mhz bandwidth the throughput is faster than some cables.

I use wg-quick via the parameterized systemd unit ([email protected]) all the time and never had selinux blocks. Which fedora are you on?

Seen devices with IPMI that had by design unauthenticated admin login to the IPMI from the host side that was not removable. They also could flash IPMI firmware from the host. So if your server with such an IPMI is infected you can't trust reimaging it via IPMI because that can be hijacked as well.

Shoutout to Heads for even attempting to make this. But even that is far from complete. At least the UX is a little better than standard.

Lennart is technically doing good work. While his tools are less complicated than the current hilariously convoluted standard boot process, they are still too complicated to use well.

He also misses the point with the attack scenarios. If you luks encrypt your data and choose a good passphrase, the brunt is done against theft. Protecting against bad passwords is futile in the long run. (Will elaborate if requested.) That someone images your drive for offline bruteforce or manipulates your boot binaries is rare. The true benefit of signed boot chain is to have security patches work reteoactively, "compromise recovery". Automated attacks and malware from the internet side are way more common.

Imagine one of your daemons is compromised. As long as it does not escalate privileges, it can only gain persistence via corruptable data files or config accessible to itself. Now a patch comes along that closes the hole that reinfects the daemon. The malware will not start on daemon restart.

With signed booting you can bring that to the kernel and root.

Signed booting with rollback protection into a known good state. As long as the malware is not part of that system it won't run on launch.

But who signs my stuff, especially my own scripts and automation? Me of course, if I had good tooling.

If that became normal malware would just steal the key.

A TPM or other keybearer device lets you conditionally unlock a signing key.

So to sign, you can boot your system into a runlevel / target / ... that does not run auxiliary scripts from writable locations. If that state is measured by the TPM, you can sign.

With good enough tooling this is workable.

If implemented well, this even helps maintenance of the system.

In the state of things now, its a horrible convoluted mess that doesnt give extra security but 10 more points at which you can break your boot.

+ UEFI itself is again a complexity monster full of holes on very many machines. The whole x86 preboot stack amd or intel is a horrible complexity monster.

Many surface brand devices had a toggle in the bios for something like "security level" for years. Which is a switch between Windows signing CA only and Windows signing CA + 3rd party CA. The latter allows shim distros to boot. You can still set your own keys on them.

If firmware not buggy: If Secureboot is set up to use keys which never signed any bootloader that lets you modify the system pre-login.: Then it kind of matters.

If you have a gaming board: Firmware integrity checks are mostly easy bypassable.

If you use a distro's default bootloader scheme: You can compromise the OS pre-login.

The CA that signed the shim, the Microsoft 3rd party CA, sogned all kinds of crap that lets you run whatever you want from that.

The whole shim thing is not about security but having stuff boot smoothly without screwing with bios settings.

If you want it to give you integrity, then you need to roll your own keys and make sure the firmware has no signature check bugs letting one bypass signature checks.

All this is orthogonal to self sovereign systems.

On Intel thats gone. You can't have a secure and sovereign firmware game without extreme extra effort.

The whole secureboot roll your own keys is the next best thing of harm reduction.

If we had some way of making the system actually static and separate from userdata. And a way to boot that prevents any persistent executable code from the userdata part from running. So as to have a clean state. From that on we could bind that state to unlock signing keys to sign the next version of the booted stuff. Then we could have nice security properties minus whatever is bad in the Intel TCB.

Compromise to root would actually be nicely reversible.

Immutable distros exist. But they are not there yet in terms of conditional readonly-ness.

Thats interesting. Are you ok for a 1on1 talk about this topic?

Both do that.

You compare apples with oranges. Because if you'd compare the apples , you'd notice one of them has no usable E2E.

Yes oranges umm phone numbers is a problem. They have that both. Only one can additionally read the contents.

Thats for now the price for a normie interface.

First goalposts first.

Irs super complicated to use. And you need an existing Telegram account to actually handle that cryptocurrency to buy these pseudo-numbers outside of the telephone namespace. Guess what you need to register those. An actual working phone number.

That repo is not fully open.

Release lag -> Telegram foss needs to wrangle the release every time. Fdroid CI takes its time.