Körning med minsta möjliga behörighet och disciplin kring sudo

De flesta säkerhetsintrång i automatisering sker inte på grund av exotiska sårbarheter, utan för att skript körs med större behörigheter än de behöver. Ett cron-jobb som körs som root men bara behöver rotera en loggfil är en olycka som väntar på att inträffa.

Principen om minsta möjliga behörighet innebär att varje process endast ska använda de behörigheter som krävs för att utföra sin uppgift — och inga fler. I Bash-skript innebär det att:

• köra som en obehörig användare när det är möjligt
• höja till root endast för de specifika kommandon som kräver det
• släppa behörigheterna så snart det privilegierade arbetet är klart
• aldrig lagra eller ärva autentiseringsuppgifter utanför deras giltighetsområde

Den här lektionen går igenom de konkreta teknikerna: avgränsning av sudo, nedväxling med su, skydd för UID-validering och härdning av sudoers — för att bygga en disciplinerat utformad behörighetsmodell för produktionsskript.

Före varje kodblock som verkligen kräver root bör skriptet verifiera att det körs med förväntat effektivt UID. Anta aldrig; kontrollera alltid.

$EUID är en särskild Bash-variabel som innehåller det effektiva användar-ID:t för den aktuella processen. Root har alltid EUID 0. Om du kontrollerar detta i början av skriptet — eller runt ett privilegierat kodblock — förhindrar du oavsiktlig körning med fel identitet.

Använd följande skyddsmönster:

Vissa skript behöver legitimt root-behörighet. I så fall vänder du på kontrollen: avsluta direkt om root saknas, i stället för att låta skriptet nå ett privilegierat systemanrop och ge ett förvirrande behörighetsfel mitt under körningen.

Genom att kombinera den tidiga avslutningen med ett användbart hjälpmeddelande blir skripten självbeskrivande:

Det vanligaste misstaget är att placera sudo högst upp i ett skript och sedan köra allt som root. Tillämpa i stället sudo endast på det exakta kommando som behöver det — allt annat körs som din vanliga användare.

Detta begränsar skadeomfattningen: om en angripare injicerar kod i ditt skript kan angriparen endast köra de delar som inte har sudo framför sig med root-behörighet.

Jämför de två mönstren nedan. Det andra är betydligt säkrare:

Att anropa sudo somecommand i ett skript är bara säkert om filen sudoers är konfigurerad för att tillåta exakt det kommandot — och inget mer. Undvik regler som ALL=(ALL) NOPASSWD: ALL för tjänstekonton.

Begränsa i stället reglerna till specifika kommandon med specifika argument med hjälp av den syntax som är säker att redigera med visudo. Viktiga fält i en sudoers-regel:

• User — vem som får anropa sudo
• Host — på vilken dator (använd ALL för portabilitet)
• RunAs — vilken identitet som ska antas (nästan alltid root)
• Command — fullständig absolut sökväg, eventuellt med bokstavliga argument

Exempel på strikta regler för ett tjänstekonto för distribution (deployer):

När ett skript startar som root, till exempel via systeminitiering eller cron som körs som root, men det mesta arbetet bör utföras av en obehörig användare, ska du uttryckligen släppa behörigheterna i stället för att köra hela skriptet som root.

Två verktyg för detta:

• su -s /bin/bash -c 'command' username — startar ett skal som username och kör kommandot
• runuser -u username -- command args — föredras i Linux för byte inom root-ägda skript; renare än su

Mönstret nedan visar en root-ägd wrapper för distribution som växlar till användaren app för den faktiska applikationslogiken:

Du behöver inte alltid växla till en fullständig skalsession. sudo -u username command kör ett enskilt kommando som den angivna användaren och återgår sedan till den anropande identiteten. Detta är användbart för att ändra filer som ägs av ett tjänstekonto utan att ge kontot interaktiv åtkomst.

Kombinera detta med en sudoers-regel som tillåter exakt den kombinationen av användare och kommando:

En subtil angreppsyta är miljövariabler som ärvs av en sudo-session. Som standard återställer sudo miljön, men felkonfigurerade åsidosättningar av env_keep eller env_reset kan skicka angriparkontrollerade variabler som LD_PRELOAD, PATH eller PYTHONPATH till privilegierade kommandon.

Rekommenderade metoder:

• Använd alltid absoluta sökvägar i skript som körs med sudo — förlita dig aldrig på $PATH
• Skicka endast de variabler du uttryckligen behöver: sudo env VAR=value /path/to/cmd
• Undvik env_keep += PATH eller env_keep += LD_* i sudoers
• Använd sudo -E endast när du har full kontroll över och litar på den anropande miljön

Även när en sudoers-regel tillåter ett specifikt skript kan skriptet få godtyckliga argument, om regeln inte begränsar även dem. En vanlig fallgrop:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Detta tillåter sudo /opt/scripts/manage.sh restart — men även sudo /opt/scripts/manage.sh --arbitrary-flag. Om manage.sh skickar argument vidare till privilegierade underkommandon utan kontroll har du ett problem.

Använd djupförsvar: validera argumenten inne i det privilegierade skriptet såväl som i sudoers:

När ett skript tillfälligt måste ha tillgång till en privilegierad fil, autentiseringsuppgift eller resurs använder du Bashs trap för att säkerställa att städningen utförs även vid fel eller signaler. Det förhindrar privilegieläckage – till exempel att en tillfällig setuid-binär eller en socket som ägs av root lämnas kvar om skriptet kraschar.

Mönstret nedan skapar en temporär fil som root, använder den och tar sedan bort den – garanterat genom en trap på EXIT:

Minsta privilegium är enklare att upprätthålla när varje privilegiehöjning loggas med sammanhang: vem som körde vad, när och varför. Kombinera två lager:

1. sudo självt – /var/log/auth.log (Debian/Ubuntu) eller /var/log/secure (RHEL) registrerar automatiskt varje sudo-anrop
2. Granskningslogg på skriptnivå – skriv en strukturerad post i början av varje privilegierad funktion, så att avsikten registreras tillsammans med systemloggen

Med en enkel funktion för strukturerad loggning blir granskningsspåren konsekventa och enkla att söka i med grep:

I den här lektionen har du lärt dig tekniker för att köra Bash-skript med minsta möjliga privilegier i varje steg. Här är en kort sammanfattning av de viktigaste principerna:

• Skydda med $EUID – avbryt direkt om skriptet körs med fel identitet, oavsett om det innebär att root ska nekas eller krävas
• Begränsa sudo till enskilda kommandon – höj aldrig privilegierna för ett helt skript; använd sudo endast på de rader som faktiskt behöver det
• Skriv strikta sudoers-regler – ange fullständiga absoluta sökvägar och bokstavliga argument; undvik jokertecken och ALL
• Sänk privilegierna med runuser eller sudo -u – när ett skript som startats av root måste lämna över arbetet till en användare utan privilegier ska du använda rätt verktyg i stället för att köra allt som root
• Använd absoluta sökvägar – förlita dig aldrig på $PATH i privilegierad kod; hårdkoda sökvägar till binärer för att förhindra kapning
• Validera argument i privilegierade skript – sudoers-reglerna är den första försvarslinjen, inte den enda; använd tillåtelselistor
• Använd trap och städa upp – använd trap cleanup EXIT för att garantera att temporära privilegierade resurser förstörs även vid fel
• Logga varje privilegiehöjning – strukturerade granskningsposter i kombination med sudos inbyggda syslog ger spårbarhet för varje privilegierad åtgärd

När dessa metoder tillämpas konsekvent minskar de angreppsytan i din automatisering från root-at-all-times till root-only-where-provably-necessary – kännetecknet för härdad Bash-kod av produktionskvalitet.