{"id":638,"date":"2026-11-12T08:51:28","date_gmt":"2026-11-12T08:51:28","guid":{"rendered":"https:\/\/d-mashina.net\/?p=638"},"modified":"2026-11-12T08:51:28","modified_gmt":"2026-11-12T08:51:28","slug":"systemd-hardening-10-nastavitev-za-varnejse-linux-storitve","status":"publish","type":"post","link":"https:\/\/d-mashina.net\/index.php\/2026\/11\/12\/systemd-hardening-10-nastavitev-za-varnejse-linux-storitve\/","title":{"rendered":"systemd hardening: 10 nastavitev za varnej\u0161e Linux storitve"},"content":{"rendered":"

Linux stre\u017enik je lahko redno posodobljen, za\u0161\u010diten s po\u017earnim zidom in pravilno konfiguriran, pa ima \u0161e vedno storitve z bistveno ve\u010d pravicami, kot jih dejansko potrebujejo.<\/em><\/p>\n

Ko govorimo o varnosti Linux stre\u017enikov, najve\u010dkrat pomislimo na SSH, po\u017earni zid, SELinux, AppArmor, Fail2ban in redne varnostne posodobitve.<\/p>\n

Vse to je pomembno. Toda eno od precej uporabnih varnostnih orodij imamo na ve\u010dini sodobnih Linux distribucij \u017ee name\u0161\u010deno, pa ga pogosto premalo izkori\u0161\u010damo.<\/p>\n

To je systemd<\/strong>.<\/p>\n

Ve\u010dina administratorjev ga uporablja predvsem za zagon, ustavljanje in nadzor storitev. Vendar systemd omogo\u010da tudi omejevanje dostopa do datote\u010dnega sistema, privilegijev, naprav, omre\u017enih funkcij in nekaterih sistemskih klicev.<\/p>\n

S pravilno konfiguracijo lahko precej zmanj\u0161amo \u0161kodo, ki bi jo povzro\u010dila kompromitirana storitev.<\/p>\n

Poglejmo deset nastavitev, ki jih je smiselno poznati.<\/p>\n

1. NoNewPrivileges=true<\/h2>\n

Ena prvih nastavitev, ki jih je vredno preveriti, je:<\/p>\n

NoNewPrivileges=true<\/code><\/p>\n

Ta prepre\u010duje, da bi proces in njegovi potomci pri izvajanju novih programov pridobili dodatne privilegije, na primer prek mehanizmov setuid ali datote\u010dnih capabilities.<\/p>\n

Pomembno je razumeti, da nastavitev ne odvzame privilegijev, ki jih proces \u017ee ima.<\/p>\n

\u010ce storitev \u017ee te\u010de kot root, bo \u0161e vedno imela precej\u0161nje pravice.<\/p>\n

Zato je nastavitev najbolj uporabna v kombinaciji z izvajanjem storitve pod namenskim neprivilegiranim uporabnikom in dodatnimi omejitvami.<\/p>\n

Kdaj previdno?<\/strong> Pri storitvah, ki morajo legitimno izvajati privilegirane pomo\u017ene programe.<\/p>\n

2. PrivateTmp=true<\/h2>\n

Za \u0161tevilne aplikacije je imenik \/tmp<\/code> prostor za za\u010dasne datoteke.<\/p>\n

Te\u017eava nastane, \u010de storitev uporablja skupne za\u010dasne imenike, do katerih lahko dostopajo tudi drugi procesi.<\/p>\n

Z nastavitvijo:<\/p>\n

PrivateTmp=true<\/code><\/p>\n

storitev dobi svoj zasebni pogled na \/tmp<\/code> in \/var\/tmp<\/code>.<\/p>\n

To zmanj\u0161a tveganje za dolo\u010dene napade prek za\u010dasnih datotek in nenamerne konflikte med aplikacijami.<\/p>\n

Kdaj previdno?<\/strong> \u010ce si aplikacije med seboj izmenjujejo datoteke prek skupnega \/tmp<\/code>, lahko tak\u0161na omejitev prekine njihovo delovanje.<\/p>\n

3. ProtectSystem=strict<\/h2>\n

To je ena zanimivej\u0161ih mo\u017enosti.<\/p>\n

ProtectSystem=strict<\/code><\/p>\n

Za storitev naredi skoraj celotno datote\u010dno hierarhijo samo za branje, z dolo\u010denimi izjemami za sistemske virtualne datote\u010dne sisteme.<\/p>\n

Aplikacija tako ne more kar poljubno spreminjati sistemskih konfiguracij in datotek.<\/p>\n

Toda kaj, \u010de mora pisati v \/var\/lib\/myapp<\/code>?<\/p>\n

Za to obstaja nastavitev:<\/p>\n

ReadWritePaths=\/var\/lib\/myapp<\/code><\/p>\n

Z njo dolo\u010dimo izjemo, ki omogo\u010da pisanje na navedeno pot, \u010de to dopu\u0161\u010dajo tudi obi\u010dajna dovoljenja in na\u010din priklopa datote\u010dnega sistema.<\/p>\n

\u0160e bolj\u0161a mo\u017enost za storitve, ki jih sami razvijamo, je pogosto uporaba StateDirectory=<\/code> in RuntimeDirectory=<\/code>.<\/p>\n

Kdaj previdno?<\/strong> Pri podatkovnih bazah, stre\u017eni\u0161kih aplikacijah in drugih storitvah, ki pi\u0161ejo na ve\u010d razli\u010dnih lokacij. Pred uvedbo je treba popisati vse potrebne poti.<\/p>\n

4. ProtectHome=true<\/h2>\n

Ali spletna storitev res potrebuje dostop do osebnih imenikov uporabnikov?<\/p>\n

V ve\u010dini primerov ne.<\/p>\n

ProtectHome=true<\/code><\/p>\n

Prepre\u010di dostop do vsebine imenikov \/home<\/code>, \/root<\/code> in \/run\/user<\/code> znotraj storitve.<\/p>\n

To je \u0161e posebej koristno pri procesih, ki so dosegljivi prek omre\u017eja.<\/p>\n

\u010ce pride do kompromitacije aplikacije, je ena od mo\u017enih poti napadalca iskanje uporabni\u0161kih podatkov, konfiguracij in zasebnih klju\u010dev.<\/p>\n

Ta nastavitev lahko tak\u0161en dostop omeji.<\/p>\n

Kdaj previdno?<\/strong> Pri storitvah, ki namerno uporabljajo podatke v doma\u010dih imenikih, na primer nekaterih SFTP, backup in uporabni\u0161kih aplikacijah.<\/p>\n

5. PrivateDevices=true<\/h2>\n

Linux storitve obi\u010dajno ne potrebujejo neposrednega dostopa do fizi\u010dnih naprav.<\/p>\n

PrivateDevices=true<\/code><\/p>\n

Storitev dobi omejen, zaseben pogled na \/dev<\/code>, z osnovnimi navideznimi napravami, ki jih obi\u010dajne aplikacije potrebujejo.<\/p>\n

S tem prepre\u010dimo neposreden dostop do \u0161tevilnih naprav, na primer diskov.<\/p>\n

To je pomembno, ker lahko kompromitiran proces z ustreznimi privilegiji in dostopom do naprav povzro\u010di precej ve\u010d \u0161kode kot obi\u010dajna uporabni\u0161ka aplikacija.<\/p>\n

Kdaj previdno?<\/strong> Pri storitvah za upravljanje strojne opreme, diskov, USB naprav, virtualizacije in drugih programih, ki potrebujejo dejanske naprave.<\/p>\n

6. ProtectKernelTunables=true<\/h2>\n

Linux jedro omogo\u010da spreminjanje \u0161tevilnih parametrov prek \/proc\/sys<\/code>, \/sys<\/code> in podobnih vmesnikov.<\/p>\n

Obi\u010dajna aplikacija teh nastavitev ne bi smela spreminjati.<\/p>\n

ProtectKernelTunables=true<\/code><\/p>\n

Omeji mo\u017enost spreminjanja sistemskih nastavitev jedra znotraj storitve.<\/p>\n

To pomaga zmanj\u0161ati tveganje, da bi kompromitirana aplikacija posegala v nastavitve operacijskega sistema.<\/p>\n

Kdaj previdno?<\/strong> Pri namenskih sistemskih storitvah, ki morajo spreminjati parametre jedra.<\/p>\n

7. ProtectKernelModules=true<\/h2>\n

Nalaganje modulov Linux jedra je privilegirana operacija.<\/p>\n

Ve\u010dina aplikacij tega ne potrebuje.<\/p>\n

ProtectKernelModules=true<\/code><\/p>\n

Prepre\u010duje, da bi proces neposredno nalagal ali odstranjeval module jedra, in odstrani ustrezno capability iz dovoljenega nabora.<\/p>\n

To ne pomeni, da jedro v nobenem primeru ne more samodejno nalo\u017eiti modula zaradi drugih sistemskih dogodkov.<\/p>\n

Pomeni pa, da ima sama storitev eno nevarno mo\u017enost manj.<\/p>\n

Kdaj previdno?<\/strong> Pri storitvah za upravljanje modulov, virtualizacije in namenske strojne opreme.<\/p>\n

8. ProtectControlGroups=true<\/h2>\n

Linux uporablja cgroups za upravljanje in omejevanje procesov ter sistemskih virov.<\/p>\n

S pomo\u010djo:<\/p>\n

ProtectControlGroups=true<\/code><\/p>\n

storitev ne more poljubno spreminjati hierarhije kontrolnih skupin prek obi\u010dajnih vmesnikov cgroup.<\/p>\n

Pri ve\u010dini obi\u010dajnih spletnih in aplikacijskih storitev za to ni potrebe.<\/p>\n

Kdaj previdno?<\/strong> Pri upravljalnikih kontejnerjev in drugih storitvah, ki morajo same ustvarjati ali upravljati cgroups.<\/p>\n

9. CapabilityBoundingSet=<\/h2>\n

Linux capabilities omogo\u010dajo razdelitev tradicionalnih privilegijev uporabnika root na manj\u0161e sklope.<\/p>\n

Namesto da procesu dovolimo vse, mu lahko omejimo nabor zmogljivosti.<\/p>\n

Na primer:<\/p>\n

CapabilityBoundingSet=<\/code><\/p>\n

Prazna vrednost odstrani vse capabilities iz dovoljenega nabora storitve.<\/p>\n

To je lahko odli\u010dna izbira za preprosto aplikacijo, ki te\u010de kot navaden uporabnik in ne potrebuje privilegiranih operacij.<\/p>\n

\u010ce potrebuje dolo\u010deno capability, lahko dovolimo samo tisto, ki je res potrebna.<\/p>\n

Kdaj previdno?<\/strong> Pri procesih, ki potrebujejo privilegirana omre\u017ena vrata, dolo\u010dene sistemske operacije ali upravljanje drugih procesov.<\/p>\n

Pri uporabi te nastavitve moramo razumeti tudi razliko med CapabilityBoundingSet=<\/code> in AmbientCapabilities=<\/code>.<\/p>\n

10. SystemCallFilter=<\/h2>\n

Linux programi komunicirajo z jedrom prek sistemskih klicev.<\/p>\n

Nekateri klici so namenjeni zelo specifi\u010dnim opravilom, ki jih obi\u010dajna storitev ne potrebuje.<\/p>\n

systemd omogo\u010da filtriranje sistemskih klicev s pomo\u010djo seccomp.<\/p>\n

Primer:<\/p>\n

SystemCallFilter=@system-service<\/code><\/p>\n

Ta skupina vklju\u010duje sistemske klice, obi\u010dajno potrebne za \u0161tevilne sistemske storitve.<\/p>\n

S tem lahko omejimo dostop do drugih funkcionalnosti jedra.<\/p>\n

Vendar skupina ni univerzalna re\u0161itev. Nekateri jeziki, izvajalna okolja in aplikacije potrebujejo dodatne sistemske klice.<\/p>\n

Kdaj previdno?<\/strong> Pri Javi, dolo\u010denih runtime okoljih, aplikacijah s kompleksnim upravljanjem pomnilnika ter programih, ki uporabljajo posebne sistemske funkcije.<\/p>\n

Filtre je treba preizkusiti tudi med dejanskimi opravili aplikacije, ne le ob njenem zagonu.<\/p>\n

\n
\n<\/div>\n

Kako vse skupaj uporabimo v praksi?<\/h2>\n

Najbolje je za\u010deti pri eni manj kriti\u010dni storitvi.<\/p>\n

Recimo, da imamo lastno aplikacijo myapp.service<\/code>, ki te\u010de kot uporabnik myapp<\/code> in svoje podatke shranjuje v \/var\/lib\/myapp<\/code>.<\/p>\n

V systemd ustvarimo dodatno konfiguracijo, imenovano drop-in override<\/em>:<\/p>\n

sudo systemctl edit myapp.service<\/code><\/p>\n

Vnesemo nastavitve, prilagojene dejanskim potrebam aplikacije.<\/p>\n

Pomembno: vseh deset omejitev ne smemo na slepo uporabiti za vsako storitev. Konfiguracija, ki je primerna za preprosto spletno aplikacijo, lahko povsem onemogo\u010di Docker, sistem za varnostne kopije ali podatkovno bazo.<\/p>\n

Ko shranimo konfiguracijo, preverimo njeno veljavnost, ponovno za\u017eenemo storitev in pregledamo dnevnike.<\/p>\n

Spremembe, ki vplivajo na omre\u017eje, zapisovanje datotek ali sistemske klice, lahko povzro\u010dijo te\u017eave \u0161ele pri dolo\u010denih opravilih.<\/p>\n

Zato samo uspe\u0161en zagon storitve \u0161e ni dokaz, da vse deluje.<\/p>\n

Kako preverimo varnost storitve?<\/h2>\n

systemd ima uporabno vgrajeno orodje:<\/p>\n

sudo systemd-analyze security myapp.service<\/code><\/p>\n

Izpi\u0161e seznam varnostnih nastavitev in oceno izpostavljenosti.<\/p>\n

Ni\u017eja ocena praviloma pomeni stro\u017eje omejitve systemd.<\/p>\n

Pomembno pa je, da ta ocena ni celovita varnostna revizija.<\/p>\n

Ne preverja vseh ranljivosti programske opreme, aplikacijske avtentikacije, pravil po\u017earnega zidu in drugih zunanjih varnostnih mehanizmov.<\/p>\n

Storitev z nizko oceno ima lahko \u0161e vedno kriti\u010dno ranljivost. Storitev z visoko oceno pa ni nujno ranljiva.<\/p>\n

Ocena je zato predvsem pomo\u010d pri prepoznavanju mo\u017enosti za dodatno utrjevanje.<\/p>\n

Zakaj ne bi preprosto vsega omogo\u010dili?<\/h2>\n

Ker varnost ni tekmovanje v \u0161tevilu omogo\u010denih nastavitev.<\/p>\n

\u010ce storitvi odvzamemo nekaj, kar dejansko potrebuje, smo lahko povzro\u010dili izpad.<\/p>\n

Pri produkcijskih Linux stre\u017enikih zato priporo\u010dam postopno uvajanje.<\/p>\n

Najprej pregled obstoje\u010de konfiguracije, nato ena ali nekaj omejitev, funkcionalni preizkusi in \u0161ele potem nadaljnje utrjevanje.<\/p>\n

\u0160e posebej previdni moramo biti pri storitvah, kot so Docker, Podman, NFS, podatkovne baze, sistemi za varnostne kopije in programska oprema za virtualizacijo.<\/p>\n

Te pogosto potrebujejo bistveno \u0161ir\u0161i dostop do jedra, naprav ali datote\u010dnega sistema.<\/p>\n

Zaklju\u010dek<\/h2>\n

Varnost Linux stre\u017enika ni odvisna samo od tega, ali imamo name\u0161\u010dene zadnje posodobitve in pravilno nastavljen po\u017earni zid.<\/p>\n

Pomembno je tudi, kaj lahko posamezna storitev dejansko po\u010dne.<\/p>\n

\u010ce spletni aplikaciji ni treba dostopati do doma\u010dih imenikov uporabnikov, ji tega ni treba dovoliti.<\/p>\n

\u010ce proces ne potrebuje dostopa do fizi\u010dnih naprav, ga lahko omejimo.<\/p>\n

In \u010de aplikacija ne potrebuje privilegiranih operacij, ni razloga, da ji pustimo nepotrebne capabilities.<\/p>\n

Najbolj\u0161a varnostna nastavitev ni tista, ki omogo\u010di najve\u010d omejitev, ampak tista, ki storitvi dovoli natanko toliko, kolikor potrebuje za svoje delo.<\/strong><\/p>\n

systemd nam za tak\u0161no na\u010delo najmanj\u0161ih privilegijev ponuja zelo uporabna orodja.<\/p>\n

Le uporabiti jih moramo.<\/p>\n

Ste \u017ee uporabili systemd sandboxing na svojih produkcijskih Linux stre\u017enikih? Katere nastavitve so vam povzro\u010dile najve\u010d te\u017eav?<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Linux stre\u017enik je lahko redno posodobljen, za\u0161\u010diten s po\u017earnim zidom in pravilno konfiguriran, pa ima \u0161e vedno storitve z bistveno ve\u010d pravicami, kot jih dejansko potrebujejo. Ko govorimo […]<\/p>\n","protected":false},"author":1,"featured_media":639,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,153,113],"tags":[156,155,159,157,154,158],"class_list":["post-638","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-systemd","category-varnost","tag-debian","tag-linux-hardening","tag-linux-security","tag-oracle-linux","tag-systemd","tag-systemd-sandboxing"],"_links":{"self":[{"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/posts\/638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/comments?post=638"}],"version-history":[{"count":1,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/posts\/638\/revisions"}],"predecessor-version":[{"id":640,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/posts\/638\/revisions\/640"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/media\/639"}],"wp:attachment":[{"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/media?parent=638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/categories?post=638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/d-mashina.net\/index.php\/wp-json\/wp\/v2\/tags?post=638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}