OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
◉

systemd-enhetsbygger

Lag tryggere tjenesteenheter
Resultat.service
[Unit]
Description=Otho worker
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=otho
WorkingDirectory=/opt/otho
ExecStart=/opt/otho/bin/worker
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

Innledning

systemd-enhetsbyggeren genererer en tjenesteenhet (en .service-fil) med herdingsalternativer som er lette å glemme: en ikke-root-bruker, NoNewPrivileges, PrivateTmp, ProtectSystem=strict og ProtectHome.

systemd lar deg beskrive hva en tjeneste kan røre. Den genererte enheten er et forsvarlig utgangspunkt for en bakgrunnsarbeider, en agent eller enhver langvarig prosess.

Mål

  • Generer en syntaktisk korrekt .service-enhet fra navn, kommando, bruker og arbeidskatalog.
  • Bruk grunnleggende herding: dedikert bruker, omstart ved feil, ingen nye privilegier, privat /tmp og skrivebeskyttede systembaner.
  • Hold enheten lesbar slik at en administrator kan justere den før distribusjon.

Inndata

  • Beskrivelse (fritekst).
  • ExecStart — den absolutte banen til den kjørbare filen.
  • Tjenestebruker — kontoen uten privilegier som tjenesten kjører som.
  • Arbeidskatalog (valgfritt).

Slik fungerer det

Verktøyet setter sammen tre seksjoner. [Unit] erklærer beskrivelsen og ordner tjenesten etter network-online.target. [Service] setter Type=simple, brukeren og arbeidskatalogen, ExecStart og Restart=on-failure med 5 sekunders forsinkelse.

Deretter følger herdingsdirektivene: NoNewPrivileges=true blokkerer å skaffe nye privilegier gjennom setuid-binærfiler; PrivateTmp=true gir tjenesten sin egen /tmp; ProtectSystem=strict gjør hele filsystemet skrivebeskyttet bortsett fra eksplisitt tillatte baner; ProtectHome=true skjuler /home, /root og /run/user.

[Install] erklærer WantedBy=multi-user.target slik at enheten kan aktiveres med systemctl enable.

Testbart eksempel

Prøv det — analysen kjører lokalt i nettleseren din.

Eksempel

Beskrivelse: Otho worker
ExecStart:  /opt/otho/bin/worker
Bruker:     otho
Katalog:    /opt/otho

Forventet utdata

[Unit]
Description=Otho worker
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=otho
WorkingDirectory=/opt/otho
ExecStart=/opt/otho/bin/worker
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

Les utdataene

  • Lagre utdataene som /etc/systemd/system/<navn>.service, kjør sudo systemctl daemon-reload, deretter sudo systemctl start <navn>.
  • Hvis tjenesten må skrive til systembaner, vil ProtectSystem=strict blokkere det — legg til ReadWritePaths eller flytt skrivbare data til arbeidskatalogen.
  • Enheten er en mal: juster TimeoutStartSec, ressursgrenser (MemoryMax, CPUQuota) og capabilities (CapabilityBoundingSet) etter arbeidsmengden.

Risikoer

  • Å kjøre en tjeneste som root med nettverkstilgang er den høyeste risikostandarden; den genererte enheten unngår det, men sjekk at ExecStart-binærfilen din eies av root.
  • ProtectSystem=strict kan bryte tjenester som skriver utenfor arbeidskatalogen — test før produksjon.
  • Restart=on-failure beskytter ikke mot krasj som avsluttes med exitkode 0; vurder Restart=always for kritiske arbeidere.

Begrensninger

  • Verktøyet genererer filen; det kan ikke teste at den kjørbare filen din starter eller at tillatelsene er riktige.
  • Det genererer ikke socket-aktivering, timere eller komplekse avhengighetsgrafer.
  • Harding er en grunnlinje — en reell gjennomgang bør vurdere capabilities, seccomp og nettverksnavnerom.

Offisielle referanser

FAQ

Hvorfor en dedikert bruker for hver tjeneste?

En dedikert bruker uten privilegier begrenser hva en kompromittert tjeneste kan gjøre: den kan ikke lese andre brukeres filer eller skrive utenfor egne baner. Root bør reserveres for de få tjenestene som virkelig trenger det.

Hva gjør NoNewPrivileges=true?

Det hindrer tjenesten og dens barn i å skaffe privilegier gjennom setuid-binærfiler eller lignende mekanismer, selv om slike binærfiler finnes på systemet.

Hva er ProtectSystem=strict?

Det gjør hele filsystemet skrivebeskyttet for tjenesten, bortsett fra eksplisitt tillatte baner. Det er det sterkeste ProtectSystem-nivået og passer godt med tjenester som bare skriver til arbeidskatalogen eller /tmp.