Hvordan man bruger SUID, SGID og Sticky Bits på Linux

• Dave McKay

  @TheGurkha

• 26. februar 2020, 8:00am EDT

SUID, SGID og Sticky Bits er kraftfulde specielle tilladelser, som du kan angive for eksekverbare filer og mapper i Linux. Vi vil fortælle om fordelene – og de potentielle faldgruber – ved at bruge dem.

De er allerede i brug

Indbygning af sikkerhed i et flerbrugerstyresystem giver flere dilemmaer. Tag f.eks. det (tilsyneladende) grundlæggende koncept med adgangskoder. De skal alle gemmes, så hver gang en person logger ind, kan systemet sammenligne den adgangskode, han skriver, med den gemte kopi. Da adgangskoderne naturligvis er nøglerne til kongeriget, skal de beskyttes.

På Linux er gemte adgangskoder beskyttet på to måder: de er krypterede, og kun en person med root-privilegier kan få adgang til den fil, der indeholder adgangskoderne. Det lyder måske fint, men det giver et dilemma: Hvis kun personer med root-rettigheder kan få adgang til gemte adgangskoder, hvordan ændrer de personer, der ikke har denne adgang, så deres adgangskoder?

Hæv din status

Sædvanligvis 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, kører den med roots tilladelser. Det betyder, at passwd-kommandoen frit kan få adgang til de gemte adgangskoder i /etc/shadow-filen.

Det ideelle ville være en ordning, hvor alle på systemet kunne starte passwd-programmet, men hvor passwd-programmet beholdt roots forhøjede rettigheder. Dette ville give enhver mulighed for at ændre sin egen adgangskode.

Ovenstående scenarie er præcis, hvad Bit’en Set User ID (SUID) gør. Den kører programmer og kommandoer med filens ejers rettigheder i stedet for med rettighederne for 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 indeholder SUID-ordningen, som gør det muligt at køre programmer med et sæt midlertidigt lånte tilladelser – men det er kun halvdelen af sikkerhedshistorien.

Kontrolmekanismen, der forhindrer en person i at arbejde med en anden persons adgangskode, er indeholdt i passwd-programmet, ikke i operativsystemet og SUID-ordningen.

Programmer, der kører med forhøjede rettigheder, kan udgøre en sikkerhedsrisiko, hvis de ikke er skabt med en “security by design”-tankegang. Det betyder, at sikkerhed er det første, man overvejer, og derefter bygger man på det. Du skal ikke skrive dit program og så forsøge at give det et lag sikkerhed bagefter.

Den største fordel ved open source-software er, at du selv kan se på kildekoden eller henvise til pålidelige peer-reviews af den. I kildekoden til passwd-programmet er der kontroller, så du kan se, om den person, der kører programmet, er root. Forskellige muligheder er tilladt, hvis en person er root (eller en person, der bruger sudo).

Dette er koden, der registrerer, om en person er root.

Det følgende er et eksempel, hvor der tages højde for det. Fordi root kan ændre alle adgangskoder, behøver programmet ikke at bekymre sig om de kontroller, som det normalt udfører for at se, hvilke adgangskoder personen har tilladelse til at ændre. Så for roots vedkommende springer det over disse kontroller og forlader kontrolfunktionen.

Med de centrale Linux-kommandoer og hjælpeprogrammer kan du være sikker på, at der er indbygget sikkerhed i dem, og at koden er blevet gennemgået mange gange. Selvfølgelig er der altid truslen om endnu ukendte exploits. Der kommer dog hurtigt patches eller opdateringer til at dukke op for at imødegå alle nyligt identificerede sårbarheder.

Det er tredjepartssoftware – især software, der ikke er open source – du skal være yderst forsigtig med at bruge SUID med. Vi siger ikke, at du ikke skal gøre det, men hvis du gør det, skal du sikre dig, at det ikke udsætter dit system for en risiko. Du ønsker ikke at hæve privilegierne for et program, der ikke vil styre sig selv og den person, der kører det, korrekt.

Linux-kommandoer, der bruger SUID

Nedenstående er nogle få 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 markeret med rødt, hvilket indikerer, at SUID-bitten er sat.

Rettighederne til en fil eller mappe repræsenteres normalt af tre grupper af tre tegn: rwx. Disse står for read (læse), write (skrive) og execute (udføre). Hvis bogstaverne er til stede, er der givet den pågældende tilladelse. Hvis der derimod er en bindestreg (-) i stedet for et bogstav til stede, er denne tilladelse ikke givet.

Der er tre grupper af disse tilladelser (fra venstre mod højre): tilladelser til filens ejer, til medlemmer af filens gruppe og til andre. Når bit SUID er indstillet på en fil, repræsenterer et “s” ejerens eksekveringstilladelse.

Hvis bit SUID er indstillet på en fil, der ikke har eksekveringsmuligheder, angiver et stort “S” dette.

Vi vil se på et eksempel. Den almindelige bruger dave skriver kommandoen passwd:

passwd

Kommandoen passwd beder dave om sin nye adgangskode. Vi kan bruge kommandoen ps til at se detaljerne om de kørende processer.

Vi bruger ps med grep i et andet terminalvindue og leder efter passwd-processen. Vi bruger også indstillingerne -e (every process) og -f (full-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, fordi det er den for passwd-processen dave, som dave har startet.

Vi kan se, at passwd-processen kører på samme måde, som den ville gøre, hvis root havde startet den.

Setting the SUID Bit

Det er nemt at ændre SUID-bitten med chmod. Den symbolske tilstand u+s indstiller SUID-bitten, og den symbolske tilstand u-s sletter SUID-bitten.

For at illustrere nogle af koncepterne for SUID-bitten har vi oprettet et lille program ved navn htg. Det ligger i rodmappen for dave-brugeren dave, og det har ikke sat SUID-bitten. Når det udføres, viser det det reelle og det effektive bruger-id (UID).

Det reelle UID tilhører den person, der har startet programmet. Det effektive ID er den konto, som programmet opfører sig, som om det var blevet startet af.

Vi skriver følgende:

ls -lh htg

./htg

Når vi kører den lokale kopi af programmet, kan vi se, at det reelle og det effektive ID begge er indstillet til dave. Så det opfører sig præcis som et normalt program skal.

Lad os kopiere det til mappen /usr/local/bin, så andre kan bruge det.

Vi skriver følgende, idet vi bruger chmod til at sætte SUID-bitten, og kontrollerer derefter, at den er sat:

sudo cp htg /usr/local/bin

sudo chmod u+s /usr/local/bin/htg

ls -hl /usr/local/bin/htg

Så programmet er kopieret, og SUID-bitten er sat. Vi kører det igen, men denne gang kører vi kopien i mappen /usr/local/bin:

htg

Selv om dave startede programmet, er det effektive ID indstillet til root-brugeren. Så hvis mary starter programmet, sker der det samme, som vist nedenfor:

htg

Det rigtige ID er mary, og det effektive ID er root. Programmet kører med root-brugerens tilladelser.

RELATERET: Sådan bruges chmod-kommandoen på Linux

Bitten SGID

Bitten Set Group ID (SGID) minder meget om bit SUID. Når SGID-bitten er indstillet på en eksekverbar fil, indstilles den effektive gruppe til filens gruppe. Processen kører med tilladelserne for medlemmerne af filens gruppe og ikke med tilladelserne for den person, der har startet den.

Vi har justeret vores htg-program, så det også viser den effektive gruppe. Vi ændrer gruppen i htg-programmet til at være bruger marys standardgruppe, mary. Vi bruger også de symbolske tilstande u-s og g+s med chown til at fjerne bit SUID og indstille SGID.

Det gør vi ved at skrive 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 bit SGID betegnet med “s” i grupperettighederne. Bemærk også, at gruppen er indstillet til mary, og at filnavnet nu er fremhævet med gult.

Hvor vi kører programmet, skal vi fastslå, hvilke grupper dave og mary tilhører. Vi bruger kommandoen id med indstillingen -G (grupper) for at udskrive alle gruppe-id’er. Derefter kører vi programmet htg som dave.

Vi skriver følgende kommandoer:

id -G dave

id -G mary

htg

ID’et på standardgruppen for mary er 1001, og den effektive gruppe for programmet htg er 1001. Så selv om det blev startet af dave, kører det med tilladelserne for medlemmerne i gruppen mary. Det er det samme, som hvis dave var blevet medlem af gruppen mary.

Lad os anvende bit SGID på en mappe. Først opretter vi en mappe kaldet “work”, og ændrer derefter dens gruppe til “nørd”. Derefter indstiller vi SGID-bitten på mappen.

Når vi bruger ls til at kontrollere indstillingerne for mappen, bruger vi også indstillingen -d (directory), så vi ser detaljerne for 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

Den SGID bit og “nørd”-gruppen er indstillet. Disse vil påvirke alle elementer, der oprettes i mappen work.

Vi skriver følgende for at gå ind i mappen work, oprette en mappe kaldet “demo” og kontrollere dens egenskaber:

cd work

mkdir demo

ls -lh -d demo

Den SGID bit og “geek”-gruppen anvendes automatisk på mappen “demo”.

Lad os skrive følgende for at oprette en fil med kommandoen touch og kontrollere dens egenskaber:

touch useful.sh

ls -lh useful.sh

Gruppen for den nye fil er automatisk indstillet til “nørd”.”

RELATERET: Sådan bruges chown-kommandoen på Linux

The Sticky Bit

The sticky bit får sit navn fra sit historiske formål. Når den blev sat på en eksekverbar fil, markerede den over for operativsystemet, at tekstdelene af den eksekverbare fil skulle holdes i swap, hvilket gjorde deres genbrug hurtigere. På Linux påvirker sticky bit’en kun en mappe – at indstille den på en fil ville ikke give mening.

Når du indstiller sticky bit’en på en mappe, kan folk kun slette filer, der tilhører dem, inden for denne mappe. De kan ikke slette filer, der tilhører en anden person, 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 fælles filopbevaring. Filerne er beskyttet, fordi ingen igen kan slette andres filer.

Lad os oprette en mappe med navnet “shared”. Vi bruger den symbolske tilstand o+t med chmod til at indstille den sticky bit på denne mappe. Derefter ser vi på tilladelserne på denne mappe samt på 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 sticky bit’en er indstillet, er den eksekverbare bit i det “andre” 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, hvor alle filtilladelser er indstillet for ejer, gruppe og andre (derfor er de fremhævet med grønt). De bruges som delte placeringer til midlertidige filer.

Med disse tilladelser burde alle i teorien kunne gøre hvad som helst. Den klæbende bit tilsidesætter dem dog, og ingen kan slette en fil, der ikke tilhører ham.

Reminder

Det følgende er en hurtig tjekliste over det, vi dækkede ovenfor, til fremtidig reference:

• SUID virker kun på filer.
• Du kan anvende SGID på mapper og filer.
• Du kan kun anvende sticky-bitten på mapper.
• Hvis indikatorerne “s“, “g” eller “t” vises med store bogstaver, er den eksekverbare bit (x) ikke blevet indstillet.