{"id":20666,"date":"2026-08-15T11:49:11","date_gmt":"2026-08-15T09:49:11","guid":{"rendered":"https:\/\/webhosting.de\/linux-capabilities-minimalprinzip-serverdienste-root-sicherheit-kernel\/"},"modified":"2026-08-15T11:49:11","modified_gmt":"2026-08-15T09:49:11","slug":"linux-funktioner-minimalprincipen-servertjaenster-root-saekerhet-kaernan","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/linux-capabilities-minimalprinzip-serverdienste-root-sicherheit-kernel\/","title":{"rendered":"Linux-kapaciteter ist\u00e4llet f\u00f6r root: minimalprincipen f\u00f6r servertj\u00e4nster"},"content":{"rendered":"<p>Ich setze <strong>linux capabilities<\/strong> ein, um Serverdienste nach dem Minimalprinzip zu betreiben und so nur die absolut n\u00f6tigen Teilrechte zu vergeben. Dadurch reduziere ich die <strong>Angriffsfl\u00e4che<\/strong> sp\u00fcrbar, ohne Funktionen zu blockieren.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>Least-Privilege<\/strong> konsequent: Dienste erhalten nur exakt ben\u00f6tigte F\u00e4higkeiten.<\/li>\n  <li><strong>Feingranular<\/strong> statt Root: Rund 40\u201350 Capabilities ersetzen Vollzugriff.<\/li>\n  <li><strong>Trennung<\/strong> von Prozessen: Privilege Separation mindert Schaden bei Exploits.<\/li>\n  <li><strong>File<\/strong> Capabilities: Rechte direkt an Bin\u00e4rdateien binden.<\/li>\n  <li><strong>Auditierbar<\/strong>: getcap liefert klare Sicht auf Sonderrechte.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-capabilities-server-4217.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Warum Root riskant ist \u2013 und wie Capabilities das \u00e4ndern<\/h2>\n\n<p>Fr\u00fcher lief fast jeder Serverdienst mit <strong>Root-Rechten<\/strong>, was bei einer Kompromittierung sofort zur System\u00fcbernahme f\u00fchren konnte. Heute teile ich Rechte gezielt auf, indem ich Capabilities wie <code>CAP_NET_BIND_SERVICE<\/code> f\u00fcr Ports unter 1024 vergebe und alle anderen m\u00e4chtigen Rechte entferne. So darf der Webserver binden, aber keine Kernelmodule laden oder Dateibesitzer \u00e4ndern, was die <strong>Sicherheit<\/strong> deutlich anhebt. Eine klare Trennung der Aufgaben macht Angriffe weniger wirkungsvoll, weil ein ausgenutzter Prozess nur begrenzte Aktionen durchf\u00fchren darf. Wer mehr Struktur in dieses Konzept bringen will, kann Rechte sehr fein <a href=\"https:\/\/webhosting.de\/linux-capabilities-root-rechte-granular-aufteilen-sicherheitskonzept\/\">granular aufteilen<\/a> und so kritische Operationen systematisch einschr\u00e4nken. Aus einem monolithischen Root-Dienst entsteht damit ein Set aus Diensten mit kleinsten, klar definierten Befugnissen.<\/p>\n\n<h2>So funktionieren Capability-Sets im Kernel<\/h2>\n\n<p>Jeder Prozess besitzt mehrere <strong>Capability-Sets<\/strong>, die der Kernel bei sensiblen Aktionen pr\u00fcft. Das Effective-Set entscheidet, was ein Prozess jetzt sofort darf, w\u00e4hrend das Permitted-Set den Pool m\u00f6glicher Rechte enth\u00e4lt. \u00dcber das Inheritable-Set kann ich steuern, was beim <code>execve()<\/code> an Kindprozesse \u00fcbergeht, was gerade bei Wrappern und Start-Skripten z\u00e4hlt. Das Bounding-Set definiert eine harte Obergrenze, sodass bestimmte F\u00e4higkeiten nie wieder erlangt werden k\u00f6nnen, selbst bei Fehlern in der Anwendung. Mit dem Ambient-Set gebe ich Capabilities ohne SUID an regul\u00e4re Programme weiter und halte den <strong>Angriffsweg<\/strong> klein. Diese Sets zusammen erlauben mir eine sehr feine Steuerung, die weit \u00fcber das klassische Alles-oder-Nichts von UID 0 hinausgeht.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Set<\/th>\n      <th>Zweck<\/th>\n      <th>Typische Nutzung<\/th>\n      <th>Risiko bei Fehlkonfiguration<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Effective<\/td>\n      <td>Jetzt wirksame F\u00e4higkeiten<\/td>\n      <td>Pr\u00fcfung jeder privilegierten Operation<\/td>\n      <td>Prozess kann sofort zu viel<\/td>\n    <\/tr>\n    <tr>\n      <td>Permitted<\/td>\n      <td>Pool erlaubter F\u00e4higkeiten<\/td>\n      <td>Quelle f\u00fcr das Effective-Set<\/td>\n      <td>Unn\u00f6tige Reserven bleiben greifbar<\/td>\n    <\/tr>\n    <tr>\n      <td>Inheritable<\/td>\n      <td>Vererbbare F\u00e4higkeiten<\/td>\n      <td>Kontrollierte Weitergabe bei execve()<\/td>\n      <td>Kinder erben Rechte unn\u00f6tig<\/td>\n    <\/tr>\n    <tr>\n      <td>Bounding<\/td>\n      <td>Obere Grenze aller Rechte<\/td>\n      <td>Dauerhafte Ausschl\u00fcsse definieren<\/td>\n      <td>Zur\u00fcckholen m\u00e4chtiger Rechte m\u00f6glich<\/td>\n    <\/tr>\n    <tr>\n      <td>Ambient<\/td>\n      <td>Weitergabe ohne SUID<\/td>\n      <td>Regul\u00e4re Programme erhalten Capabilities<\/td>\n      <td>Breitere, stille Rechtevergabe<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Wichtig in der Praxis sind zwei zus\u00e4tzliche Aspekte: Erstens entscheiden <em>Securebits<\/em> dar\u00fcber, ob ein Prozess nach einem Wechsel der Benutzer-ID (z. B. via <code>setuid()<\/code>) seine Capabilities beh\u00e4lt. Mit <code>PR_SET_KEEPCAPS<\/code> l\u00e4sst sich das gezielt steuern \u2013 typischer Ablauf: kurzzeitig als Root starten, ben\u00f6tigte Sockets oder Ressourcen anlegen, UID auf einen unprivilegierten Nutzer wechseln und nur die erforderlichen Capabilities weiterf\u00fchren. Zweitens gilt: Das <em>Bounding-Set<\/em> ist endg\u00fcltig in der aktuellen Prozesslinie. Wer hier fr\u00fch im Startpfad \u00fcberfl\u00fcssige F\u00e4higkeiten entfernt, kann sp\u00e4ter selbst durch Fehlkonfigurationen keine \u201everbotenen\u201c Rechte mehr erlangen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_capabil_5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dateirechte mit File Capabilities steuern<\/h2>\n\n<p>Statt einem Dienst dauerhafte <strong>Sonderrechte<\/strong> einzur\u00e4umen, binde ich sie lieber direkt an die Bin\u00e4rdatei. \u00dcber <code>setcap cap_net_bind_service=+eip \/usr\/bin\/node<\/code> erlaube ich Port-Bindings, ohne dass der Prozess als Root laufen muss. Mit <code>getcap \/usr\/bin\/node<\/code> oder rekursiv <code>getcap -r \/ 2>\/dev\/null<\/code> pr\u00fcfe ich die Vergabe und behalte die Kontrolle. Entfernen klappt \u00fcber <code>setcap -r \/pfad\/zum\/binary<\/code>, sodass ich tempor\u00e4re Rechte nach dem Einsatz wieder zur\u00fccknehme. Beim Kopieren gehen Capabilities h\u00e4ufig verloren, daher sichere ich sie im Deployment explizit, um <strong>Regressions<\/strong> zu vermeiden. So bleiben Builds reproduzierbar und Rechte bleiben stets nachvollziehbar dokumentiert.<\/p>\n\n<p>File Capabilities leben als Extended Attribute (<code>security.capability<\/code>) auf dem Dateisystem. Das setzt ein f\u00e4higes FS und passende Mount-Optionen voraus. Tools wie <code>tar<\/code> und <code>rsync<\/code> m\u00fcssen XAttrs explizit mitnehmen (z. B. <code>tar --xattrs<\/code>, <code>rsync -XA<\/code>), sonst verschwinden Rechte stillschweigend. Paketmanager k\u00f6nnen Capabilities in Post-Install-Schritten setzen; ich halte das bevorzugt im Build\/Release-Prozess fest, um \u00dcberraschungen bei Upgrades zu vermeiden. Kritisch ist au\u00dferdem: Interpreter-Skripte (z. B. mit Shebang) erben File Capabilities nicht wie ELF-Binaries. M\u00e4chtige F\u00e4higkeiten auf <em>Interpreter<\/em> zu legen, ist ohnehin riskant \u2013 ich entkoppele lieber und arbeite mit dedizierten, kleinen Helfer-Binaries.<\/p>\n\n<h2>Minimalprinzip f\u00fcr Serverdienste in der Praxis<\/h2>\n\n<p>Ich starte Webserver als unprivilegierten Nutzer und erteile ausschlie\u00dflich <code>CAP_NET_BIND_SERVICE<\/code>, damit der Prozess an 80\/443 binden darf und keine weiteren <strong>Privilegien<\/strong> mitbringt. Dateien und Verzeichnisse steuere ich weiter \u00fcber POSIX-Rechte sowie optional MAC-Profile, wodurch Konfiguration und Inhalte getrennt abgesichert bleiben. Monitoring- oder Logging-Agents erhalten gezielte Netzwerkrechte und Leserechte auf Logs, aber keinerlei Befugnisse f\u00fcr System\u00e4nderungen. In Container-Umgebungen reduziere ich den Capability-Satz zus\u00e4tzlich und kombiniere ihn mit Systemcall-Filtern, um das Verhalten eng zu halten. Diese Kombination senkt die Wirkung erfolgreicher Exploits und erh\u00f6ht die <strong>Transparenz<\/strong> der tats\u00e4chlichen Befugnisse. Dienste bleiben funktionsf\u00e4hig, doch der Handlungsspielraum bleibt klein.<\/p>\n\n<p>Statt Capabilities zu vergeben, eliminiere ich sie manchmal ganz: Socket-Aktivierung stellt privilegierte Listener (z. B. 443\/tcp) \u00fcber den Init-Prozess bereit und \u00fcbergibt nur den offenen Datei-Deskriptor an den Dienst. Der Applikationsprozess ben\u00f6tigt dann kein <code>CAP_NET_BIND_SERVICE<\/code> mehr. Ebenso lassen sich einmalige Root-Aktionen (z. B. PID-Verzeichnis anlegen) vorab erledigen und danach konsequent Rechte abgeben. Je weniger F\u00e4higkeiten <em>\u00fcberhaupt<\/em> im Spiel sind, desto robuster bleibt das System gegen Kettenfehler.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-faehigkeiten-serverdienste-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Privilege Separation sauber umsetzen<\/h2>\n\n<p>Ich zerlege umfangreiche Dienste in mehrere <strong>Teilprozesse<\/strong>, die jeweils nur die n\u00f6tigen Capabilities tragen. Ein Frontend-Prozess terminiert TLS und bindet an Ports, besitzt aber keine Dateisystemrechte f\u00fcr kritische \u00c4nderungen. Ein Backend-Prozess verarbeitet Daten intern, hat minimale Leserechte auf Konfiguration und spricht mit Datenbanken ohne eigene Netzwerkf\u00e4higkeiten. Administrative Jobs wie Logrotation oder Wartung laufen \u00fcber dedizierte Tools mit zeitlich begrenzten F\u00e4higkeiten. Greift ein Angreifer einen Teil an, bleibt der Rest des Systems unbehelligt, weil die <strong>Berechtigungen<\/strong> eng definiert sind. So skaliert Sicherheit mit der Struktur der Anwendung statt mit allm\u00e4chtigen Systemrechten.<\/p>\n\n<p>F\u00fcr diese Aufteilung bietet sich eine klare Start-Orchestrierung an. In klassischen Setups erledigt das ein Supervisor; auf heutigen Systemen nutze ich bevorzugt systemd, weil es Capabilities, cgroups und Namespaces direkt integriert. So kann ich Netz-Frontend, Worker und Admin-Tools jeweils mit eigener Sandbox starten, Ressourcen begrenzen und im Fehlerfall automatisch neu starten lassen \u2013 ohne jemals pauschal Root-Rechte zu verteilen.<\/p>\n\n<h2>Security Controls kombinieren: POSIX, MAC und Capabilities<\/h2>\n\n<p>Capabilities wirken am besten, wenn ich sie mit klassischen <strong>Dateirechten<\/strong> und MAC-Systemen kombiniere. SELinux oder AppArmor k\u00f6nnen Aktionen trotz vergebener Capabilities weiter einschr\u00e4nken und damit Mehrfachschutz erzeugen. So darf ein Prozess zwar an einen Port binden, wird aber durch eine Policy am Lesen sensibler Dateien gehindert. Wer den Unterschied der Ans\u00e4tze vertiefen will, findet einen klaren Vergleich in <a href=\"https:\/\/webhosting.de\/selinux-vs-apparmor-linux-security-server-hardening-schutz\/\">SELinux vs. AppArmor<\/a> und kann dann eine passende Policy-Strategie w\u00e4hlen. In Summe entsteht ein Verteidigungsverbund, der Angriffe auf mehreren Ebenen stoppt und die <strong>Angriffsfl\u00e4che<\/strong> weiter verkleinert. Rechtevergabe bleibt damit pr\u00fcfbar, wiederholbar und konsistent.<\/p>\n\n<p>Besonders restriktiv wird es, wenn ich zus\u00e4tzlich <em>NoNewPrivileges<\/em> aktiviere: Prozesse und Kinder d\u00fcrfen dann keine neuen Privilegien erlangen (z. B. \u00fcber SUID oder neu gesetzte File Capabilities). Zusammen mit einer harten Capability-Bounding-Liste entsteht eine Sicherheitsbarriere, die selbst bei fehlerhafter Konfiguration sp\u00e4tere Privilegaufweitung verhindert.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_night_4537.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Capabilities sicher verteilen und auditieren<\/h2>\n\n<p>Ich halte den zugewiesenen <strong>F\u00e4higkeitensatz<\/strong> so klein wie m\u00f6glich und vermeide alles, was nach \u201ezweitem Root\u201c klingt, etwa <code>CAP_SYS_ADMIN<\/code>. Interpreter wie Python, Perl oder Shells erhalten keine m\u00e4chtigen Capabilities, weil ihr Funktionsumfang leicht missbraucht werden kann. Mit regelm\u00e4\u00dfigen Audits \u00fcber <code>getcap -r \/ 2>\/dev\/null<\/code> sp\u00fcre ich Ausrei\u00dfer auf und r\u00e4ume auf. Bin\u00e4rdateien mit Capabilities liegen schreibgesch\u00fctzt, geh\u00f6ren Root und befinden sich nicht in Pfaden, die normale Nutzer ver\u00e4ndern d\u00fcrfen. Zus\u00e4tzlich pr\u00fcfe ich eigene Binaries vor jedem Release und dokumentiere \u00c4nderungen, damit <strong>Review<\/strong> und Reproduktion zuverl\u00e4ssig klappen. So bleibt die Rechtevergabe beherrschbar und Anpassungen bleiben nachvollziehbar.<\/p>\n\n<p>Zur Laufzeit pr\u00fcfe ich Prozesse \u00fcber <code>\/proc\/&lt;pid&gt;\/status<\/code> (Felder <code>CapEff<\/code>, <code>CapPrm<\/code>, <code>CapInh<\/code>). Das liefert die Hex-Werte der aktiven Sets und zeigt sofort, ob eine Anwendung mehr kann als vorgesehen. Werkzeuge wie <code>capsh --print<\/code> oder <code>getpcaps &lt;pid&gt;<\/code> erleichtern das Debugging. Mit dem Linux-Audit-Subsystem protokolliere ich zus\u00e4tzlich \u00c4nderungen an Capabilities oder an <code>security.capability<\/code>-Attributen von Dateien, um Manipulationen nachzuverfolgen. Wer Capabilities als Konfigurationsobjekt behandelt und \u00c4nderungen streng reviewt, macht Audits reproduzierbar und vereinfacht Compliance-Nachweise.<\/p>\n\n<h2>H\u00e4ufige Stolperfallen und wie ich sie vermeide<\/h2>\n\n<p>Eine typische Falle: Beim Kopieren gehen <strong>Attribute<\/strong> verloren, wodurch Dienste pl\u00f6tzlich nicht mehr starten oder umgekehrt zu wenig eingeschr\u00e4nkt sind. Ich sichere Capabilities daher explizit im Build, oder ich vergebe sie im Post-Install-Schritt automatisiert. Ein weiterer Fehler ist die gro\u00dfz\u00fcgige Nutzung von Allzweck-Capabilities, die mehr \u00f6ffnen als n\u00f6tig. Besser ist es, konkrete F\u00e4higkeiten wie <code>CAP_NET_RAW<\/code> oder <code>CAP_CHOWN<\/code> nur dort einzusetzen, wo sie eine reale Funktion freischalten. Auch das Ambient-Set setze ich sparsam ein, damit sich keine ungewollte <strong>Weitergabe<\/strong> verbreitet. Wer gezielt reduziert und regelm\u00e4\u00dfig pr\u00fcft, verhindert Sicherheitsl\u00fccken durch Bedienfehler.<\/p>\n\n<p>Ebenfalls wichtig: SUID-Binaries systematisch abschaffen. Wo fr\u00fcher SUID n\u00f6tig war (z. B. ICMP senden), l\u00e4sst sich oft mit <code>CAP_NET_RAW<\/code> arbeiten \u2013 oder, besser noch, die Funktion in einen kleinstm\u00f6glichen Helfer-Prozess mit sehr engem Pflichtenheft auslagern. Au\u00dferdem vermeide ich, Capabilities auf tempor\u00e4re oder von Nutzern beschreibbare Pfade zu legen. Ein strenges Eigent\u00fcmer- und Deploy-Regime (Root:root, 0755\/0555, unver\u00e4nderliche Pfade) verhindert Rechte-\u201eVerlust\u201c durch ersetzte Binaries.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxfaehigkeitenroot4238.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Capabilities in Containern und DevSecOps<\/h2>\n\n<p>In Container-Umgebungen reduziere ich die <strong>Capabilities<\/strong> aggressiv und entferne alles, was der Workload nicht zwingend braucht. Zus\u00e4tzlich lege ich ein <a href=\"https:\/\/webhosting.de\/seccomp-linux-kernel-sicherheit-anwendungen-einschraenken-sandbox-guard\/\">Seccomp-Profil<\/a> an, das riskante Systemcalls sperrt und so eine weitere H\u00fcrde einzieht. In Build-Pipelines definiere ich Capabilities deklarativ, teste sie in Staging und erfasse sie versioniert. Compliance profitiert, weil ich das Least-Privilege-Prinzip nachweisen und Rechte\u00e4nderungen l\u00fcckenlos dokumentieren kann. So bleiben Container eng gef\u00fchrt, ohne ihre Aufgaben zu behindern, und die <strong>Angriffsfl\u00e4che<\/strong> bleibt klein. In Kombination mit Images, die nur das N\u00f6tigste enthalten, steigt die Sicherheit zus\u00e4tzlich.<\/p>\n\n<p>Wichtig im Container-Kontext: Capabilities sind in Namespaces <em>relativ<\/em>. Innerhalb eines User-Namespaces kann ein Prozess zwar \u201eRoot\u201c sein, seine F\u00e4higkeiten wirken aber nur auf die zugeh\u00f6rigen Namespaces \u2013 das senkt den Schadenradius deutlich. Im Gegenzug ist \u201e<code>--privileged<\/code>\u201c praktisch immer tabu: Es schaltet die harte Bounding-Grenze ab und \u00f6ffnet weit mehr als n\u00f6tig. Ich starte Container daher standardm\u00e4\u00dfig mit \u201ealles dropen, gezielt adden\u201c und erg\u00e4nze <em>NoNewPrivileges<\/em>, cgroup-Limits und schreibgesch\u00fctzte Mounts. F\u00fcr Dienste, die nur lauschen m\u00fcssen, nutze ich Socket-Aktivierung oder Sidecars, um ganz ohne zus\u00e4tzliche Capabilities auszukommen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverminimalprinzip-9284.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemd-Beispiel: Capabilities deklarativ beschr\u00e4nken<\/h2>\n\n<p>In service-Units lege ich fest, was ein Prozess maximal darf \u2013 klar, wiederholbar und versionskontrollierbar. Ein kompaktes Beispiel f\u00fcr einen Webdienst, der nur an 443 binden darf und sonst stark eingeschr\u00e4nkt ist:<\/p>\n\n<pre><code>[Unit]\nDescription=Minimaler Webdienst ohne Root\n\n[Service]\nUser=web\nGroup=web\nExecStart=\/usr\/bin\/my-web\nAmbientCapabilities=CAP_NET_BIND_SERVICE\nCapabilityBoundingSet=CAP_NET_BIND_SERVICE\nNoNewPrivileges=yes\nProtectSystem=strict\nProtectHome=yes\nPrivateTmp=yes\nReadWritePaths=\/var\/lib\/my-web\nRestrictAddressFamilies=AF_INET AF_INET6\nSystemCallFilter=@basic-io @network-io\nLockPersonality=yes\nMemoryDenyWriteExecute=yes\n\n[Install]\nWantedBy=multi-user.target\n<\/code><\/pre>\n\n<p>Die Kombination aus <code>AmbientCapabilities<\/code> und einer harten <code>CapabilityBoundingSet<\/code> sorgt daf\u00fcr, dass der Dienst nur die eine n\u00f6tige F\u00e4higkeit erh\u00e4lt und nichts dar\u00fcber hinaus. <code>NoNewPrivileges<\/code> verhindert nachtr\u00e4gliche Privilegaufwertung, <code>ProtectSystem<\/code> und <code>ReadWritePaths<\/code> regeln den Schreibzugriff, und ein enger Systemcall-Filter unterbindet unn\u00f6tige Kernel-Eintrittspunkte.<\/p>\n\n<h2>H\u00e4ufig gebrauchte Capabilities \u2013 und sichere Alternativen<\/h2>\n\n<ul>\n  <li><strong>CAP_NET_BIND_SERVICE<\/strong>: Binden an Ports &lt;1024. Alternative: Socket-Aktivierung, Reverse Proxy vorlagern.<\/li>\n  <li><strong>CAP_NET_RAW<\/strong>: Rohsockets (Ping, DHCP). Alternative: kleiner Helferprozess statt breiter Interpreter-Rechte.<\/li>\n  <li><strong>CAP_CHOWN<\/strong>\/<strong>CAP_FOWNER<\/strong>: Eigent\u00fcmer\/ACL-Anpassungen. Alternative: vorbereitete Verzeichnisse, dedizierte Maintenance-Tools.<\/li>\n  <li><strong>CAP_SYS_PTRACE<\/strong>: Debugging\/Tracing \u2013 nur in Staging, nie breit in Produktion.<\/li>\n  <li><strong>CAP_SYS_ADMIN<\/strong>: \u201eZweites Root\u201c \u2013 vermeiden; konkretisieren, was wirklich gebraucht wird.<\/li>\n<\/ul>\n\n<p>Ich w\u00e4hle stets die kleinste Menge, die die ben\u00f6tigte Funktion exakt freischaltet. Falls eine Capability mehrere Angriffswege \u00f6ffnet (z. B. RAW-Sockets), kapsle ich die Funktion in einen getrennten, kurzlebigen Prozess und nehme Rechte nach getaner Arbeit wieder zur\u00fcck.<\/p>\n\n<h2>Praxis-Checkliste f\u00fcr robuste Capabilities<\/h2>\n\n<ul>\n  <li>Startet der Dienst ohne Root? Falls nein: Warum nicht \u2013 und l\u00e4sst sich das mit Socket-Aktivierung oder kleinen Helfer-Binaries l\u00f6sen?<\/li>\n  <li>Sind <em>alle<\/em> vergebenen Capabilities nachweislich erforderlich (Funktionsnachweis, Testf\u00e4lle)?<\/li>\n  <li>Ist das Bounding-Set maximal eng und fr\u00fch gesetzt?<\/li>\n  <li>Sind XAttrs im Build, bei Deployments und Backups konsistent erhalten (rsync\/tar-Flags, Package-Skripte)?<\/li>\n  <li>Verzichte ich auf Capabilities bei Interpretern und SUID-Binaries konsequent?<\/li>\n  <li>Sind Besitzer- und Dateirechte (Root:root, 0755\/0555) sowie Pfade gegen Austausch gesch\u00fctzt?<\/li>\n  <li>Greifen zus\u00e4tzliche Kontrollen (NoNewPrivileges, Seccomp, MAC-Profile)?<\/li>\n  <li>Werden Prozess-Capabilities zur Laufzeit auditiert (<code>\/proc\/&lt;pid&gt;\/status<\/code>, getpcaps) und \u00c4nderungen dokumentiert?<\/li>\n  <li>Sind Container standardm\u00e4\u00dfig mit \u201edrop all, add minimal\u201c und ohne \u201eprivileged\u201c konfiguriert?<\/li>\n<\/ul>\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p><strong>Linux<\/strong> Capabilities zerlegen klassische Root-Rechte in kleine, steuerbare Einheiten und setzen dadurch das Minimalprinzip technisch sauber um. Ich weise Diensten nur die F\u00e4higkeiten zu, die sie wirklich ben\u00f6tigen, und kombiniere das mit POSIX-Rechten sowie MAC-Policies. File Capabilities sorgen daf\u00fcr, dass Rechte direkt an Binaries h\u00e4ngen und Audits klar zeigen, wer was darf. Mit Privilege Separation, reduzierten Container-Rechten und Systemcall-Filtern begrenze ich Sch\u00e4den, falls eine Schwachstelle greift. Regelm\u00e4\u00dfige Pr\u00fcfungen, strenge Eigent\u00fcmer- und Schreibrechte und ein dokumentierter Release-Prozess halten die Vergabe schlank. So bleibt der Serverdienst funktionsf\u00e4hig, doch der <strong>Spielraum<\/strong> f\u00fcr Angreifer wird konsequent klein gehalten.<\/p>","protected":false},"excerpt":{"rendered":"<p>Uppt\u00e4ck hur Linux Capabilities till\u00e4mpar minimalprincipen f\u00f6r servertj\u00e4nster och h\u00f6jer servers\u00e4kerheten till en ny niv\u00e5 genom separering av beh\u00f6righeter.<\/p>","protected":false},"author":1,"featured_media":20659,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20666","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"136","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"linux capabilities","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20659","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20666"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20666\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20659"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20666"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20666"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}