Hardening avansat pentru servicii systemd cu namespaces, capability restrictions și system call filters

Systemd poate izola un serviciu fără să modifici codul aplicației. Poți limita directoarele vizibile, dispozitivele accesibile, capabilitățile kernelului și apelurile de sistem permise. Configurarea trebuie însă aplicată incremental: o regulă prea strictă poate opri scrierea logurilor, accesul la socket-uri, pornirea proceselor auxiliare sau funcționarea unui runtime cu JIT.

Exemplul următor presupune un serviciu numit myapp.service. Înlocuiește numele și directoarele cu cele reale.

Inventariază comportamentul serviciului

Înainte să adaugi restricții, verifică unitatea, utilizatorul, fișierele și porturile folosite:

systemctl cat myapp.service
systemctl show myapp.service \
  -p User -p Group -p ExecStart
systemctl status myapp.service
sudo ss -lntup
sudo journalctl -u myapp.service -n 100

Rulează și evaluarea systemd:

sudo systemd-analyze security myapp.service

Comanda analizează directivele de izolare și afișează un nivel estimativ de expunere. Scorul este util pentru comparații, dar nu demonstrează că aplicația este sigură și nu cunoaște toate cerințele sale funcționale.

Salvează configurația înainte de modificare:

sudo systemctl cat myapp.service \
  > /root/myapp-service-before-hardening.txt

Creează un drop-in, nu modifica unitatea furnizată de pachet

Deschide un override:

sudo systemctl edit myapp.service

Adaugă o bază de hardening pentru un serviciu web care trebuie să scrie numai în două directoare:

[Service]
NoNewPrivileges=true

PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict

ReadWritePaths=/var/lib/myapp
ReadWritePaths=/var/log/myapp

ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictNamespaces=true

LockPersonality=true
RestrictRealtime=true

CapabilityBoundingSet=
AmbientCapabilities=

SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native

ProtectSystem=strict face filesystem-ul disponibil serviciului în principal read-only. ReadWritePaths= redeschide explicit doar directoarele unde aplicația trebuie să scrie. PrivateTmp=true oferă un spațiu separat pentru /tmp și /var/tmp, iar PrivateDevices=true limitează accesul la dispozitive. Aceste mecanisme folosesc izolarea bazată pe mount namespaces.

Creează înainte directoarele necesare și setează proprietarul corect:

sudo install -d \
  -o myapp -g myapp -m 0750 \
  /var/lib/myapp /var/log/myapp

Elimină capabilitățile kernelului neutilizate

Linux capabilities împart privilegiile tradiționale ale contului root în drepturi separate, precum administrarea rețelei, încărcarea modulelor sau ocolirea permisiunilor fișierelor. CapabilityBoundingSet= stabilește limita maximă a capabilităților pe care serviciul și procesele sale le pot obține.

O valoare goală elimină toate capabilitățile:

CapabilityBoundingSet=
AmbientCapabilities=

Dacă aplicația rulează fără root, dar trebuie să deschidă direct portul 80 sau 443, păstrează numai:

CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

Nu acorda CAP_SYS_ADMIN pentru a rezolva rapid o eroare. Este o capabilitate extrem de largă și poate anula o parte importantă din izolare.

Limitează apelurile către kernel

SystemCallFilter= folosește mecanismul seccomp pentru a controla syscall-urile pe care procesul le poate utiliza. Documentația systemd recomandă, pentru numeroase servicii de lungă durată, allow-list-ul @system-service, împreună cu returnarea erorii EPERM pentru apelurile blocate.

Vezi ce conține grupul pe sistemul tău:

systemd-analyze syscall-filter @system-service

Conținutul grupurilor poate varia după arhitectură, kernel și versiunea systemd. De aceea, filtrul trebuie testat pe aceeași distribuție și versiune folosite în producție.

Pentru aplicații compilate care nu folosesc JIT poți testa suplimentar:

MemoryDenyWriteExecute=true

Nu activa această opțiune orbește pentru Java, Node.js, .NET sau alte runtime-uri care generează cod executabil în memorie.

Verifică, aplică și testează

Validează unitatea:

sudo systemd-analyze verify myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Verifică imediat:

systemctl status myapp.service
sudo journalctl -u myapp.service -b -n 100
curl -f http://127.0.0.1:8080/health
sudo systemd-analyze security myapp.service

Testează funcțiile reale: autentificare, upload, loguri, conexiuni la baza de date, procese auxiliare și restart. Când apare Permission denied sau Operation not permitted, identifică directiva responsabilă și relaxează doar controlul necesar.

Pentru revenire rapidă:

sudo systemctl revert myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Hardening-ul systemd eficient nu urmărește cel mai mic scor posibil, ci cel mai strict profil care permite toate operațiunile legitime și blochează restul.

Surse folosite

systemd.exec — namespaces, filesystem protection, capabilities și SystemCallFilter.

systemd-analyze — evaluarea securității unităților și inspectarea grupurilor de syscall-uri.

Linux manual pages — capabilities și separarea privilegiilor kernelului.