On the dynamic linker bypass specifically, have you looked at fapolicyd [1]? It uses fanotify(7) and the top of the README is:

> The restrictive policy was designed with these goals in mind:

> 1. No bypass of security by executing programs via ld.so.

> 2. Anything requesting execution must be trusted.

One correction on the table: SELinux and AppArmor shouldn't be grouped under "rename-resistant: No". AppArmor is path-based. SELinux labels are on the inode, a rename doesn't change the security context. The copy attack doesn't apply either: a process in sandbox_t creating a file in /tmp gets tmp_t via type transition, and the policy does not grant sandbox_t execute permission on tmp_t.

[1] https://github.com/linux-application-whitelisting/fapolicyd

Paying maintainers doesn't give Red Hat a magic oracle for "which commits matter for security". What you actually end up with is cherry-picking + backporting. Backporting is inherently messy, you can introduce new bugs (including security bugs) while trying to transplant fixes, and omissions are inevitable. And CVEs don't save you here: plenty of security relevant fixes never get a tidy CVE in the first place, and vendors miss fixes because they often pretend the CVE stream is "the security feed".

Greg is pretty blunt about this in the video linked in the article: "If you are not using the latest stable / longterm kernel, your system is insecure" (see 51:40-53:00 in [1]). He also calls out Red Hat explicitly for ending up "off in the weeds" with their fixes.

RHEL as an entire distribution may provide good enough security for most environments. But that is not the same claim as "the RHEL kernel is secure" or "they know exactly which commits are relevant". It is still guesswork plus backports, and you're still running behind upstream fixes (many of which will never get pulled in). It is a comfortable myth.

[1] https://www.youtube.com/watch?v=sLX1ehWjIcw&t=3099s

amazing because of the irony, yes?

From my perspective a large factor contributing to its popularity is because of FastAPIs native integration. V2 has broken so much behavior, and the library is generally fragile and slow. Credit where it is due, it is a great library that has done a lot to bring python types to more projects, but there are better solutions out there now.

I’d strongly recommend looking into msgspec. It is a much faster alternative and is largely “correct” in its implementation. It uses all of the python native type annotations without many hacks. Really it is much much faster and can actually be used for performance sensitive python workloads that need strong typing.

I have the same worry (although I have no evidence, and haven’t done much research into finding evidence).

I've slowly transitioned from FF to Chrome over the past year, for this reason. I still use both, but am trying to prepare myself for a time that comes when FF is no longer a viable primary browser.