#selinux — Public Fediverse posts

Ein Konfigurationsfehler legt die komplette .de-Zone lahm. Drei Linux-Kernel-Exploits zielen auf dasselbe Angriffsmuster. Und Daniel Stenberg beschreibt, wie KI-generierte Bug-Reports curl gleichzeitig besser und anstrengender machen.
 
Unser aktueller Security Digest ordnet ein, was die letzten Wochen wirklich relevant war:
🔐 Copy Fail, Dirty Frag, Dirty Pipe: Local Privilege Escalation bleibt eine der häufigsten Schwachstellenklassen im Linux-Kernel. Unser Take: SELinux ist kein Nice-to-have, sondern die wirksamste Gegenmaßnahme. Nicht-privilegierte Accounts sollten nicht unter unconfined_u laufen. Punkt.
🌐 DNSSEC-Ausfall der .de-Zone: Ein Signierfehler bei der DENIC hat am 05.05. gezeigt, wie fragil zentralisierte DNS-Infrastruktur sein kann.
🤖 KI und Open Source: curl erlebt nach der AI-Slop-Welle jetzt hochwertige Meldungen. Gleichzeitig steigt die Last für Maintainerinnen und Maintainer massiv.
📱 Android Intrusion Logging: Google liefert mit dem Advanced Protection Mode endlich eine echte Datenquelle für mobile Forensik. Wir empfehlen die Aktivierung für exponierte Personen und Organisationen mit erhöhtem Schutzbedarf.
 
Das Security-Modell aus dem Mobilbereich wird zunehmend zum Vorbild für Desktop und Server. Wer heute noch ohne Mandatory Access Control arbeitet, liefert eine Angriffsfläche, die sich mit wenigen Konfigurationsschritten deutlich reduzieren ließe. Den vollständigen Digest mit allen Quellen und unserer Einordnung finden Sie hier: https://research.hisolutions.com/2026/05/
 
Wie gehen Sie in Ihrer Organisation mit SELinux um? Und nutzt jemand von Ihnen bereits Android Intrusion Logging in der Vorfallsbehandlung?
 
#Cybersecurity #SELinux #DNSSEC #AndroidSecurity #OpenSource @brahms @jrt

As an aside, LMDE (Debian) works just fine for me for #gaming. #RetroArch runs great, there are no issues with Feral #Gamemode or #SELinux issues (unlike my most recent tests with Fedora or openSUSE), I use #flatpaks so my gaming applications come with their own updated mesa and other drivers, and if I need a newer kernel I could always hit up #backports. And nvidia sucks so I wouldn't bother with them anyway.

If I really needed to I could always run #testing or #unstable.

I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

- Configuring the Login node with any required or essential dependencies (such as #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

- Setup passwordless #SSH access from the Login node to the rest of the Kubernetes nodes

- Update the hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

- Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

- Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

- Installation and configuration of #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

- Deployment and configuration of #MetalLB as the cluster's load-balancer

- Deployment and configuration of #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

- Setup and configuration of #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

- Installation and configuration of #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

Besides these, there are also some other helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

Orked currently expects and supports #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my #mika helm chart repo 🥳

🔗 https://github.com/irfanhakim-as/orked

🔗 https://github.com/irfanhakim-as/charts