SUID, SGID og Sticky Bits er kraftfulde specielle tilladelser, du kan indstille til eksekverbare filer og mapper på Linux. Vi deler fordelene – og potentielle faldgruber – ved at bruge dem.
Indholdsfortegnelse
De er allerede i brug
Indbygning af sikkerhed i et flerbrugeroperativsystem byder på adskillige problemer. Tag det (tilsyneladende) grundlæggende koncept med adgangskoder, for eksempel. De skal alle gemmes, så hver gang nogen logger på, kan systemet sammenligne den adgangskode, han indtaster, med den gemte kopi. Da adgangskoder er nøglerne til riget, skal de naturligvis beskyttes.
På Linux er lagrede adgangskoder beskyttet på to måder: de er krypteret, og kun en person med root-rettigheder kan få adgang til filen, der indeholder adgangskoden. Det lyder måske fint, men det er et dilemma: Hvis kun personer med root-privilegier kan få adgang til lagrede adgangskoder, hvordan ændrer de, der ikke har den adgang, deres adgangskoder?
Forøg din status
Normalt kører Linux-kommandoer og -programmer med det samme sæt tilladelser som den person, der starter programmet. Når root kører kommandoen passwd for at ændre en adgangskode, den kører med roots tilladelser. Det betyder, at passwd-kommandoen frit kan få adgang til de lagrede adgangskoder i filen /etc/shadow.
Det, der ville være ideelt, er et skema, hvor enhver på systemet kunne starte passwd-programmet, men lade passwd-programmet beholde roots forhøjede privilegier. Dette ville give enhver mulighed for at ændre sin egen adgangskode.
Ovenstående scenarie er præcis, hvad Set User ID bit (SUID) gør. Det kører programmer og kommandoer med filejerens tilladelser i stedet for tilladelserne fra den person, der starter programmet.
Du hæver programmets status
Der er dog et andet dilemma. Personen skal forhindres i at blande sig i andres adgangskode. Linux inkorporerer SUID-skemaet, som tillader det at køre applikationer med et sæt midlertidigt lånte tilladelser – men det er kun halvdelen af sikkerhedshistorien.
Kontrolmekanismen, der forhindrer nogen i at arbejde med en anden persons adgangskode, er indeholdt i passwd-programmet, ikke operativsystemet og SUID-skemaet.
Programmer, der kører med forhøjede privilegier, kan udgøre sikkerhedsrisici, hvis de ikke er skabt med en “security by design”-tankegang. Det betyder, at sikkerhed er det første, du overvejer, og så bygger du videre på det. Skriv ikke dit program, og prøv så at give det et lag af sikkerhed bagefter.
Den største fordel ved open source-software er du kan selv se på kildekoden eller henvise til betroede peer-reviews af det. I kildekoden til passwd-programmet er der tjek, så du kan se, om personen, der kører programmet, er root. Forskellige muligheder er tilladt, hvis nogen er root (eller nogen, der bruger sudo).
Det her er koden, der registrerer, om nogen er root.
Det følgende er et eksempel, hvor der er taget højde for det. Fordi root kan ændre en hvilken som helst adgangskode, behøver programmet ikke at genere de kontroller, det normalt udfører for at se, hvilke adgangskoder personen har tilladelse til at ændre. Så for root, det springer disse kontroller over og afslutter kontrolfunktionen.
Med de centrale Linux-kommandoer og -værktøjer kan du være sikker på, at de har sikkerhed indbygget i dem, og at koden er blevet gennemgået mange gange. Selvfølgelig er der altid truslen om endnu ukendte udnyttelser. Imidlertid dukker patches eller opdateringer hurtigt op for at imødegå eventuelle nyligt identificerede sårbarheder.
Det er tredjepartssoftware – især enhver, der ikke er open source – du skal være ekstremt forsigtig med at bruge SUID med. Vi siger ikke, at du ikke gør det, men hvis du gør det, vil du være sikker på, at det ikke udsætter dit system for risici. Du ønsker ikke at ophøje privilegierne for et program, der ikke korrekt selvstyrer sig selv og den person, der kører det.
Linux-kommandoer, der bruger SUID
Følgende er et par af de Linux-kommandoer, der bruger SUID-bitten til at give kommandoen forhøjede privilegier, når den køres af en almindelig bruger:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Bemærk, at filnavnene er fremhævet med rødt, hvilket indikerer, at SUID-bitten er indstillet.
Tilladelserne på en fil eller et bibliotek er normalt repræsenteret af tre grupper af tre tegn: rwx. Disse står for læse, skrive og udføre. Hvis brevene er til stede, er den tilladelse givet. Hvis der dog er en bindestreg (-) i stedet for et bogstav, er denne tilladelse ikke givet.
Der er tre grupper af disse tilladelser (fra venstre mod højre): dem for ejeren af filen, for medlemmer af filens gruppe og for andre. Når SUID-bitten er sat på en fil, repræsenterer et “s” ejerens udførelsestilladelse.
Hvis SUID-bitten er indstillet på en fil, der ikke har eksekverbare muligheder, angiver et stort “S” dette.
Vi tager et kig på et eksempel. Almindelig bruger dave skriver kommandoen passwd:
passwd
Passwd-kommandoen beder dave om sin nye adgangskode. Vi kan bruge kommandoen ps for at se detaljerne om kørende processer.
Vi bruger ps med grep i et andet terminalvindue og se efter passwd-processen. Vi vil også bruge mulighederne -e (hver proces) og -f (fuldt format) med ps.
Vi skriver følgende kommando:
ps -e -f | grep passwd
Der rapporteres to linjer, hvoraf den anden er grep-processen, der leder efter kommandoer med strengen “passwd” i dem. Det er dog den første linje, der interesserer os, for det er den for passwd-processen, dave lancerede.
Vi kan se, at passwd-processen kører på samme måde, som den ville, hvis root havde startet den.
Indstilling af SUID-bit
Det er nemt at ændre SUID-bitten med chmod. U+s symbolsk tilstand indstiller SUID bit, og us symbolsk tilstand rydder SUID bit.
For at illustrere nogle af begreberne i SUID-bitten, lavede vi et lille program kaldet htg. Det er i rodmappen for dave-brugeren, og det har ikke SUID-bit sat. Når det udføres, viser det de rigtige og effektive bruger-id’er (UID).
Den rigtige UID tilhører den person, der lancerede programmet. Det effektive ID er den konto, programmet opfører sig, som om det var blevet lanceret af.
Vi skriver følgende:
ls -lh htg
./htg
Når vi kører den lokale kopi af programmet, ser vi, at de rigtige og effektive ID’er begge er sat til dave. Så det opfører sig lige som et normalt program skal.
Lad os kopiere det til mappen /usr/local/bin, så andre kan bruge det.
Vi skriver følgende, bruger chmod til at indstille SUID-bitten, og kontrollerer derefter, at den er blevet indstillet:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Så programmet kopieres, og SUID-bitten indstilles. Vi kører det igen, men denne gang kører vi kopien i mappen /usr/local/bin:
htg
Selvom dave lancerede programmet, er det effektive ID sat til root-brugeren. Så hvis Mary starter programmet, sker det samme, som vist nedenfor:
htg
Det rigtige ID er Mary, og det effektive ID er root. Programmet kører med root-brugerens tilladelser.
SGID-bitten
Set Group ID (SGID) bit er meget lig SUID bit. Når SGID-bitten er indstillet på en eksekverbar fil, sættes den effektive gruppe til filens gruppe. Processen kører med tilladelserne fra medlemmerne af filens gruppe snarere end tilladelserne fra den person, der startede den.
Vi tilpassede vores htg-program, så det også viser den effektive gruppe. Vi ændrer gruppen i htg-programmet til at være brugeren marys standardgruppe, mary. Vi vil også bruge us og g+s symbolske tilstande med chown til at fjerne SUID bit og indstille SGID.
For at gøre det skriver vi følgende:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Du kan se SGID-bitten angivet med “s” i gruppetilladelserne. Bemærk også, at gruppen er indstillet til mary, og filnavnet er nu fremhævet med gult.
Inden vi kører programmet, lad os fastslå, hvilke grupper dave og mary tilhører. Vi bruger id-kommandoen med -G (grupper) muligheden, for at udskrive alle gruppe-id’er. Derefter kører vi htg-programmet som dave.
Vi skriver følgende kommandoer:
id -G dave
id -G mary
htg
ID’et for standardgruppen for mary er 1001, og den effektive gruppe i htg-programmet er 1001. Så selvom det blev lanceret af dave, kører det med tilladelser fra medlemmerne i mary-gruppen. Det er det samme, som hvis dave havde sluttet sig til mary-gruppen.
Lad os anvende SGID-bitten til en mappe. Først opretter vi en mappe kaldet “arbejde” og ændrer derefter dens gruppe til “nørd”. Vi sætter derefter SGID-bitten på mappen.
Når vi bruger ls til at kontrollere indstillingerne for mappen, bruger vi også muligheden -d (mappe), så vi ser detaljerne i mappen, ikke dens indhold.
Vi skriver følgende kommandoer:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
SGID-bit og “nørd”-gruppen er indstillet. Disse vil påvirke alle elementer, der er oprettet i arbejdsbiblioteket.
Vi skriver følgende for at komme ind i arbejdsmappen, oprette en mappe kaldet “demo” og kontrollere dens egenskaber:
cd work
mkdir demo
ls -lh -d demo
SGID-bit og “nørd”-gruppen anvendes automatisk på “demo”-mappen.
Lad os skrive følgende for at oprette en fil med røre ved kommando og kontroller dens egenskaber:
touch useful.sh
ls -lh useful.sh
Gruppen af den nye fil indstilles automatisk til “nørd.”
Den Sticky Bit
Den klæbrige bit har sit navn fra dets historiske formål. Når den var indstillet til en eksekverbar, blev den markeret til operativsystemet, at tekstdelene af den eksekverbare skulle holdes i swap, hvilket gjorde deres genbrug hurtigere. På Linux påvirker den klæbrige bit kun en mappe – at sætte den på en fil ville ikke give mening.
Når du indstiller den sticky bit på en mappe, kan folk kun slette filer, der tilhører dem i den mappe. De kan ikke slette filer, der tilhører en anden, uanset hvilken kombination af filtilladelser, der er indstillet på filerne.
Dette giver dig mulighed for at oprette en mappe, som alle – og de processer, de starter – kan bruge som delt fillagring. Filerne er beskyttet, fordi igen, ingen kan slette andres filer.
Lad os oprette en mappe kaldet “delt”. Vi bruger den symbolske o+t-tilstand med chmod til at indstille den sticky bit på den mappe. Vi vil derefter se på tilladelserne på den mappe, såvel som mapperne /tmp og /var/tmp.
Vi skriver følgende kommandoer:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Hvis den klæbrige bit er indstillet, er den eksekverbare bit i “andet” sæt af filtilladelser sat til “t.” Filnavnet er også fremhævet med blåt.
Mapperne /tmp og /var/tmp er to eksempler på mapper, der har alle filtilladelser indstillet for ejeren, gruppen og andre (det er derfor, de er fremhævet med grønt). De bruges som delte placeringer for midlertidige filer.
Med disse tilladelser burde enhver teoretisk set kunne gøre hvad som helst. Den sticky bit tilsidesætter dem dog, og ingen kan slette en fil, der ikke tilhører ham.
Påmindelser
Det følgende er en hurtig tjekliste over, hvad vi dækkede ovenfor til fremtidig reference:
SUID virker kun på filer.
Du kan anvende SGID til mapper og filer.
Du kan kun anvende den sticky bit på mapper.
Hvis “s”, “g” eller “t” indikatorerne vises med store bogstaver, er den eksekverbare bit (x) ikke blevet indstillet.