- At altid arbejde som root er meget effektivt, men det risikerer sikkerhed og sporbarhed sammenlignet med at bruge sudo med færrest rettigheder.
- Sudo giver dig mulighed for at delegere specifikke kommandoer, logge handlinger og tilbagekalde tilladelser uden at dele root-adgangskoden.
- Dårlig sudo-konfiguration (grace, NOPASSWD, brede regler) åbner døren for alvorligt misbrug og sårbarheder.
- Det giver kun mening at undgå eller begrænse sudo i meget kontrollerede miljøer; i andre miljøer er det tilrådeligt at styrke og revidere brugen af det.
I GNU/Linux-verdenen siges det ofte, at det er farligt at have permanent root-adgang , både på en Linux-server og i andre miljøer som AWS. Det er dog ikke altid tydeligt forklaret, hvornår man skal bruge `sudo`, hvornår `su` er bedre, og i hvilke situationer det er bedst at undgå `sudo` eller begrænse dets brug så meget som muligt. Alt dette støder sammen med det velkendte princip om mindste privilegium, som i praksis ikke altid er let at anvende uden konstant at indtaste adgangskoder.
Hvis du arbejder med at administrere servere eller blot har en Linux-stationær computer, er det normalt at undre sig over ting som: Er det virkelig så slemt at logge ind som root? Hvorfor deaktiverer nogle distributioner root og tvinger dig til at bruge sudo? Er det usikkert for sudo at huske adgangskoden i et par minutter? Kan jeg konfigurere sudo til at være mindre "tilladelig"? I de følgende linjer vil vi se, hvordan sudo fungerer, hvordan det adskiller sig fra su og fra at logge ind direkte som root , hvilke risici hver tilgang indebærer, og hvilke anbefalede konfigurationer du kan anvende for at styrke dit systems sikkerhed uden at ofre brugervenligheden.
Rod, normale brugere og princippet om mindste privilegier
Før vi dykker ned i sudo og su, er det værd at huske på, hvad det egentlig vil sige at arbejde som root-bruger versus som en normal bruger . Rod er den almægtige konto: den kan slette enhver fil, ændre tilladelser på hvad som helst, montere eller afmontere filsystemer, oprette eller slette brugere, installere eller fjerne software og endda ændre systemets runlevel.
I et klassisk Unix-miljø ville administratoren logge direkte ind som root på en fysisk terminal eller teletype og udføre alle administrationsopgaver med den konto. Ofte ville den samme administrator have en anden "ikke-root"-konto til mere almindelige opgaver som at læse e-mails eller skrive dokumenter, men ren administration blev altid udført med root, uden filtre eller tidsbegrænsninger.
Med tiden, og især med Linux' udvidelse til flerbrugermiljøer og servere med internetforbindelse, blev princippet om mindste rettigheder etableret : hver bruger bør kun have de tilladelser, der er nødvendige for at udføre sit arbejde, hverken mere eller mindre. Hvis en bruger kun uploader billeder via SFTP til en mappe, giver det ingen mening for dem at kunne logge ind som root og manipulere med kritiske tjenester. Dette reducerer angrebsfladen, hvis den pågældende konto kompromitteres.
I praksis betyder det, at det er normalt at arbejde 99% af tiden med en "begrænset" brugerkonto , hvor man kun hæver privilegier, når man installerer pakker, genstarter tjenester eller ændrer systemkonfigurationer. Det er her, sudo og su kommer i spil, med ret forskellige tilgange.
Sudo og su: vigtige forskelle og anvendelsesscenarier
For at forstå, hvornår det giver mening at undgå sudo eller i det mindste begrænse det, skal du først være meget klar over, hvad sudo præcist gør, og hvad su gør , fordi de mange gange bruges, som om de var ækvivalente ... og det gør de ikke.
Hvad er sved, og hvad er det designet til?
sudo -kommandoen stammer fra "superuser do". Den giver en bruger mulighed for at køre et program med en anden brugers privilegier, som standard root, men den er ikke blot "en anden slags su": den er designet således, at administratoren kan delegere en eller flere specifikke kommandoer til en eller flere brugere uden at give dem fuld root-adgang.
Blandt dens vigtigste funktioner er, at den kræver brugerens adgangskode , ikke root-adgangskoden; og at alt, der udføres med `sudo`, logges i systemloggene, normalt i filer som `/var/log/auth.log` eller tilsvarende filer afhængigt af distributionen. Dette giver dig mulighed for at se, hvem der gjorde hvad og hvornår, hvilket er essentielt i produktionsmiljøer eller med flere administratorer.
Derudover tillader sudo meget detaljeret konfiguration i /etc/sudoers -filen : du kan angive, hvilke brugere eller grupper der kan udføre hvilke kommandoer, fra hvilke maskiner, med eller uden en adgangskode, eller endda afvise specifikke kommandoer, såsom at ændre root-adgangskoden. Og som om det ikke var nok, kan dens opførsel finjusteres med direktiver som timestamp_timeout , som styrer, hvor længe godkendelsen huskes, før der bedes om adgangskoden igen.
Hvad er det, og hvordan adskiller det sig?
`su` -kommandoen står for "switch user". Dens primære formål er at ændre brugeridentiteten, typisk ved at skifte til root-brugeren, selvom den kan bruges til at skifte til enhver anden systembruger. I modsætning til `sudo` beder `su` normalt om adgangskoden til målbrugeren , som er root-adgangskoden, hvis du bruger `su` alene.
Når du bruger `su` til at blive root, antager din shell root-identiteten, og du kan udføre så mange kommandoer, som du vil, med disse rettigheder, indtil du afslutter eller logger ud. Der er ingen tidsbegrænsning eller udløb for eskaleringen: brugerændringen forbliver aktiv i hele sessionen. Desuden er revisionssporet værre: Når du først er logget ind som root, er det vanskeligere at spore hver brugers handlinger, hvis flere personer deler den samme adgangskode.
Der er vigtige nuancer afhængigt af, hvordan `su` kaldes. For eksempel indlæser `su -` rodmiljøet, som om root var logget direkte ind (inklusive PATH, miljøvariabler osv.), mens `su` uden bindestregen normalt arver en del af den oprindelige brugers miljø. Der er også indstillingen `su -c "command"` , som udfører en specifik kommando som en anden bruger og derefter skifter tilbage til den oprindelige bruger.
Hybriden: sudo su og sudo -su
I mange moderne distributioner er root-kontoen som standard deaktiveret eller uden adgangskode (typisk Ubuntu), hvilket tvinger brugen af `sudo`. Alligevel er det stadig muligt at åbne en root-shell med noget i retning af `sudo su` eller `sudo su -` (svarende til `sudo -su`), som kombinerer det bedste og det værste fra begge verdener, hvis det ikke bruges med omhu.
Det, der sker der, er, at `sudo` bruger din brugeradgangskode til at køre `su` som root, uden at du behøver at kende en root-adgangskode. Fra et sikkerhedsmæssigt synspunkt er der stadig en registrering af, at du kørte `su` (`sudo`-kommandoen logges), men fra det tidspunkt arbejder du som fuld root, indtil du lukker skallen, med alle de risici, det medfører.
Fordele og ulemper ved at bruge root direkte
Nogle administratorer foretrækker stadig at arbejde direkte som den traditionelle root-bruger uden at bruge sudo, især i miljøer, de har omhyggelig kontrol over. Andre afskyr dog denne praksis og anser det for at være en unødvendig risiko. Realiteten er, at det har både fordele og ulemper.
På den positive side er det utroligt nemt at fungere som root : du opretter forbindelse via SSH som root (hvis tilladt), gør hvad du skal gøre, og det er det. Der er ingen grund til at skrive `sudo` før hver kommando, håndtere sudoer-konfigurationer eller kæmpe med kommandobegrænsninger. Til store opgaver eller lange vedligeholdelsessessioner kan dette være meget praktisk.
Men netop denne bekvemmelighed gør direkte root-adgang til en potentiel katastrofe . En tåbelig fejl som at indtaste den forkerte sti med `rm -rf` kan slette halvdelen af systemet, og der er ingen bekræftelsesdialog som i andre operativsystemer. Desuden, hvis root-adgangskoden lækkes eller stjåles, har angriberen fuld kontrol uden at skulle omgå yderligere sikkerhedslag.
En anden væsentlig ulempe er, at hvis flere administratorer deler root-adgangskoden, er der ingen nem måde at tilbagekalde adgang for kun én : du bliver nødt til at ændre root-adgangskoden og kommunikere den til alle andre, med alt det besvær, det medfører. Og handlingsloggen bliver meget mere uklar: du vil se, at "root" udførte en bestemt kommando, men ikke hvilken specifik person der stod bag den.
Nogle distributioner har taget højde for alt dette og deaktiverer som standard direkte root-login via SSH (som Debian med PermitRootLogin), eller beder endda ikke om en root-adgangskode under installationen (Ubuntu) og tvinger brugen af sudo til enhver administrativ opgave.
Svedens rolle i princippet om mindste privilegier
Hvis vi taler om seriøst at anvende princippet om mindste privilegier, er sudo stjerneværktøjet, fordi det giver dig mulighed for at finjustere præcis, hvad hver bruger med forhøjede privilegier kan gøre . Det handler ikke kun om at "sætte sudo foran kommandolinjen", men om at designe en fornuftig politik i /etc/sudoers.
For eksempel kan du konfigurere en specifik bruger til kun at genstarte nginx ved hjælp af `sudo` , men ikke stoppe det, ændre andre tjenester eller installere pakker. Dette ville svare til at tillade `sudo systemctl restart nginx`, men eksplicit nægte `sudo systemctl stop nginx`. Et andet typisk tilfælde er at give en bruger mulighed for at oprette og slette mapper med `/bin/mkdir` og `/bin/rm`, men intet mere.
Derudover muliggør sudo selektiv tilbagekaldelse af privilegier : Hvis en person ikke længere kan fungere som superbruger, kan vedkommende blot fjernes fra sudo-gruppen eller slette deres post i sudoers. Der er ingen grund til at ændre root-adgangskoden eller røre ved andre brugeres konti. Fra et operationelt og sikkerhedsmæssigt synspunkt er dette en betydelig forbedring.
Det faktum, at enhver brug af `sudo` logges med brugeren, tidspunktet, den udførte kommando og kontekst (TTY, nuværende mappe osv.), tilføjer et ekstra lag af kontrol. I revisioner eller hændelsesundersøgelser er det en guldgrube til at forstå præcis, hvad der skete, og hvem der sad ved tastaturet.
Af alle disse grunde anses det generelt for uhensigtsmæssigt at bruge root direkte i miljøer med flere administratorer eller med brugere, der har brug for specifikke rettigheder, og at den rimelige løsning mellem sudo og su næsten altid er en velkonfigureret sudo.
Risici ved en dårlig sudo-konfiguration
Selvom sudo er et meget kraftfuldt værktøj, kan det være et alvorligt problem at lade det være som standard . Mange distributioner installerer og aktiverer det næsten uden justeringer, hvilket giver hovedbrugeren beføjelser, der næsten svarer til fuld root-adgang, og med en frist på flere minutter uden at blive bedt om adgangskoden igen.
Denne " frist " (timestamp_timeout), som normalt er 5 minutter (nogle gange 15 afhængigt af distributionen), er praktisk, fordi den forhindrer dig i at skulle indtaste din adgangskode gentagne gange, når du kæder kommandoer sammen. Men fra et sikkerhedsmæssigt synspunkt er det problematisk: hvis du lader din computer være ulåst på kontoret eller et andet sted, hvor en anden måske sidder ned et øjeblik, kan alle udføre kommandoer med sudo uden at have brug for din adgangskode i den tid.
Endnu mere alvorligt er det, når brugen af `sudo` uden adgangskode (`NOPASSWD`) konfigureres eller efterlades som standard for bestemte brugere eller grupper i meget brede kommandoer (for eksempel `ALL`). Hvis en angriber på det tidspunkt formår at udføre noget som den pågældende bruger, kan de gøre stort set hvad som helst som root uden yderligere begrænsninger.
Derudover har sudo gennem årene haft sårbarheder, der kunne udnyttes, og som har gjort det muligt for brugere at omgå restriktioner eller opnå root-rettigheder. Mange af disse sårbarheder kunne kun udnyttes, hvis værktøjet var til stede og forkert konfigureret, mens dem, der fungerede uden sudo eller med meget strenge politikker, nogle gange ikke blev påvirket.
Af alle disse grunde foretrækker nogle administratorer, på trods af at de anerkender brugbarheden af sudo, kun at installere det, når det er nødvendigt, eller endda at operere uden det på specifikke servere, og altid administrere dem som root med stor omhu. Andre vælger, på distributioner hvor det er aktiveret som standard, at beskytte root med en adgangskode, tilbagekalde deres brugers sudo-tilladelser i /etc/sudoers og lade sudo være installeret, men begrænset.
Sådan hærder du sved: eliminerer nådeperioden og mere
Hvis du vil fortsætte med at bruge sudo, men minimere risiciene, er der flere foranstaltninger, du bør implementere. Den første, og den stærkt anbefalede, er at eliminere eller reducere adgangskodens respitperiode .
For at gøre dette skal du redigere /etc/sudoers -filen ved hjælp af visudo (åbn den ikke bare med nano eller vim). Visudo kontrollerer syntaksen før den gemmer; hvis der er en fejl, vil den ikke ødelægge sudo, hvilket er meget vigtigt.
I `sudoers` kan du tilføje en linje som `Defaults timestamp_timeout=0` , så `sudo` altid beder om adgangskoden uden nogensinde at gemme den. Dette er den sikreste mulighed: hver gang du vil hæve privilegier, skal du godkende igen.
Hvis du ønsker en balance mellem sikkerhed og bekvemmelighed, kan du indstille en meget kort timeout, for eksempel: `Standard timestamp_timeout=1` . Dette udløber godkendelsen efter et minut og reducerer risikoen for, at nogen udnytter din åbne og uovervågede session.
En anden nyttig foranstaltning er at begrænse særligt følsomme handlinger, såsom ændring af root-adgangskoden fra konti med sudo-rettigheder. På Debian-lignende systemer kan du tilføje en linje som: `%sudo ALL=(ALL) ALL, !/usr/bin/passwd root` , og på RHEL/CentOS/Fedora-systemer noget lignende ved hjælp af `wheel`-gruppen: `%wheel ALL=(ALL) ALL, !/usr/bin/passwd root` . På denne måde, selvom nogen har sudo-rettigheder, vil de ikke være i stand til at ændre root-adgangskoden direkte.
Det er også muligt at tvinge visse sudo-anvendelser til kun at fungere fra en interaktiv pseudoterminal , logge hver kommando til en separat fil eller begrænse PATH for at reducere risikoen for, at ondsindede binære filer slipper igennem. Alt dette styres med sudoers-direktiver og indstillinger som requiretty, log_output, secure_path og andre.
Hvornår skal man undgå sudo og vælge root eller su
Det vanskelige spørgsmål opstår: Er der situationer, hvor det giver mening at undgå sudo? Svaret er, for at være ærlig, ja, selvom det afhænger meget af konteksten, niveauet af tillid i teamet og den type system, vi taler om.
På nogle servere med høj styring, der administreres af en enkelt erfaren administrator, kan det være at foretrække altid at arbejde direkte som root eller med `su`, uden `sudo` imellem, netop for at undgå at være afhængig af et ekstra værktøj, der kan have sine egne sårbarheder eller fejlkonfigurationer. I disse tilfælde antages det, at operatøren ved, hvad de laver, og at der ikke er nogen "semi-privilegerede" brugere, som kun bestemte kommandoer kan delegeres til.
Et andet typisk scenarie involverer administratorer, der ikke ønsker at høre om den midlertidige frist eller muligheden for, at deres almindelige bruger bliver en skjult root. De foretrækker at holde root-kontoen til root-opgaver og deres almindelige konto til alt andet helt adskilt. På denne måde er skaden meget mere begrænset, hvis en sårbarhed påvirker sudo, eller hvis deres ikke-privilegerede bruger kompromitteres.
Denne tilgang har dog sine ulemper: Hvis flere personer administrerer den samme maskine, ville vi vende tilbage til problemet med at dele root-adgangskoden og ikke være i stand til at tilbagekalde tilladelser individuelt. Desuden, hvis fjernlogin udføres som root via SSH, åbner det en mere fristende dør for angribere, som kun behøver at gætte én adgangskode for at få fuld adgang.
På den anden side er der dem, der hævder, at den virkelige fare ikke er sudo i sig selv, men snarere dens forkerte konfiguration . Med andre ord argumenterer de for, at direkte root-adgang er endnu mere risikabelt end et korrekt hærdet og revideret sudo-system. Talrige hændelser fra den virkelige verden understøtter denne opfattelse: angreb, der udnytter delte root-legitimationsoplysninger, fatale kommandoer, der udføres utilsigtet, eller manglende evne til at rekonstruere begivenheder på grund af manglende brugerlogfiler.
Kort sagt giver det kun mening at undgå sudo helt i meget specifikke og kontrollerede scenarier. I de fleste produktionssystemer er den mest fornuftige tilgang at vedligeholde sudo, konfigurere det strengt (uden lange respitperioder, uden global NOPASSWD, med klare restriktioner) og reservere direkte root-adgang til meget specifikke eller nødopgaver.
Installation, tildeling og verifikation af sudo-rettigheder
I de fleste moderne distributioner er sudo installeret som standard . Hvis du får fejlen "kommandoen blev ikke fundet", når du prøver at bruge den, skal du installere den med den tilsvarende pakkehåndtering: apt i Debian/Ubuntu, yum eller dnf i CentOS/RHEL/Fedora, zypper i SLES/openSUSE osv.
Den typiske installationskommando ville se nogenlunde sådan ud: ` apt|yum|dnf|zypper install sudo` (og erstatte `sudo` med det faktiske værktøj til dit system). Når det er installeret, er næste trin at give sudo-rettigheder til de brugere, der har brug for dem.
Der er to almindelige tilgange: at tilføje en specifik regel til `/etc/sudoers` eller at tilføje brugeren til en privilegeret gruppe som `sudo` (på Debian/Ubuntu) eller `wheel` (på Red Hat, CentOS, Fedora). For at redigere `sudoers` skal du altid bruge `visudo`; for eksempel kan du tilføje en linje som `guest ALL=(ALL) NOPASSWD:ALL`, så "gæste"-brugeren kan bruge `sudo` uden en adgangskode på enhver kommando, selvom dette, som nævnt, er et følsomt sikkerhedsproblem.
Hvis du vil være mere præcis, kan du begrænse omfanget til et par kommandoer, for eksempel: guest ALL=(ALL) NOPASSWD:/bin/mkdir,/bin/rm . På denne måde vil brugeren kun kunne oprette og slette mapper med sudo uden at skulle indtaste en adgangskode, men vil ikke kunne gøre andre ting som at installere pakker eller genstarte tjenester.
Den anden mulighed er at tilføje brugeren til `sudo`-gruppen med en kommando som `sudo usermod -aG sudo guest` , eller til `wheel`-gruppen på RHEL-lignende systemer. På denne måde vil brugeren arve den generelle politik, som systemet har defineret for den pågældende gruppe i `sudoers`, hvilket generelt tillader, at næsten enhver kommando udføres som root efter godkendelse.
Hvis du nogensinde har brug for at tjekke en brugers sudo-rettigheder, kan du bruge `sudo -l` til dig selv eller `sudo -l -U username` til en anden bruger, forudsat at din konto har tilladelse til at forespørge. Outputtet vil vise dig, hvilke kommandoer de kan køre, hvilke begrænsninger der gælder, og hvilke standardværdier der bruges i deres kontekst.
Sudo vs. su: adgangskode, adfærd og sporbarhed
Sammenligningen mellem `sudo` og `su` er ikke begrænset til syntaks; der er fundamentale forskelle i, hvordan de autentificerer, hvordan de opfører sig som standard, og hvilke spor de efterlader . Dette har meget at gøre med at beslutte, hvilken en man skal bruge, og hvornår.
Med hensyn til adgangskoder bruger `sudo` den nuværende brugers adgangskode , mens `su` kræver målbrugerens adgangskode (normalt root). Det betyder, at for at flere administratorer kan bruge `su`, skal root-adgangskoden deles, hvilket betragtes som dårlig praksis, fordi det gør det vanskeligt at kontrollere og tilbagekalde adgang.
Hvad angår standardadfærd, er `sudo` designet til at udføre en enkelt kommando med forhøjede rettigheder og derefter "vende tilbage" til normal tilstand (bortset fra respitperioden). `su` ændrer derimod fuldstændigt identitet og åbner en ny shell som målbrugeren, hvilket giver dig mulighed for at udføre kommandoer uden begrænsning, indtil du beslutter dig for at afslutte. Dette gør det mere farligt, hvis du glemmer, at du stadig er root, og udsteder kommandoer uforsigtigt.
Med hensyn til logføring og revision er hver kommando med `sudo` knyttet til den virkelige identitet af den bruger , der udførte den, selvom den blev kørt som root. Med `su` vil dine handlinger, når du er logget ind som root, blot blive registreret som "root udført sådan og sådan", hvilket gør det meget vanskeligere at spore, hvilken specifik person der foretog ændringen, hvis du deler nøglen.
Endelig er der spørgsmålet om fleksibilitet: sudo tilbyder en masse granularitet, når det kommer til at begrænse kommandoer og kontekster , hvorimod eskaleringen med su normalt er total og uden nuancer: den, der kender root-adgangskoden, kan gøre praktisk talt hvad som helst, og der er ingen indbygget standardmekanisme til at begrænse dens brug til et par kommandoer.
Med alt dette i tankerne anbefaler de fleste nuværende bedste fremgangsmåder at bruge sudo som det primære værktøj til eskalering af rettigheder og reservere su til meget specifikke tilfælde (såsom su -c til at køre noget specifikt som en anden bruger, eller su til at fejlfinde et brugermiljø uden at skifte til root).
Når man ser på det store billede, er det ret tydeligt, at nøglen ikke kun er at vælge mellem `sudo`, `su` eller direkte root-adgang, men hvordan de er konfigureret, og i hvilken kontekst de bruges . Et veludviklet `sudo` uden overdrevne respitperioder, med begrænsede kommandoer og god revision, tilbyder en meget rimelig balance mellem sikkerhed og bekvemmelighed på de fleste systemer. At vælge direkte root-adgang giver mening i meget kontrollerede scenarier med ekspertadministratorer, på bekostning af at miste sporbarhed og fleksibilitet; mens det at bruge `sudo` "som det er" i mange distributioner kan ende med at være næsten lige så farligt som altid at være root. Finjustering af disse elementer og viden om, hvornår det er bedst at undgå `sudo`, er det, der gør forskellen mellem et robust system og et, der kun ser ud til at være det.
