Filtilladelser i Linux

Hej alle. Vi går aktivt i gang med arbejdet og forbereder allerede mange kraftfulde lanceringer i januar. Der er blandt andet annonceret tilmelding til en ny stream af alles yndlingskursus. "Linux-administrator". I forventning om lanceringen deler vi traditionelt oversættelser af nyttigt materiale.

Filtilladelser tilbyder et sikkert alternativ til SUID-eksekverbare filer, men kan virke lidt forvirrende i starten.

Vi ved alle, at binære SUID er dårlig beslutning ud fra et sikkerhedsmæssigt synspunkt. Heldigvis, hvis din applikation kræver nogle begrænsede privilegier, er der en mere effektiv måde kaldet filtilladelser.

Jeg sparer dig lidt tid, hvis du vil undgå at læse artiklen ovenfor i detaljer: I det væsentlige tillader filtilladelser processer, der kører som root og har derfor lov til at gøre noget for at bevare visse kapaciteter, begrænset denne listenår de dropper privilegier og køres af en uprivilegeret bruger. Det betyder, at hvis en angriber formår at kompromittere en proces ved hjælp af et bufferoverløb eller anden udnyttelse, vil de ikke være i stand til at drage fordel af andet end visse minimale privilegier, som processen faktisk har brug for.

Tilladelser er gode til tjenester, der typisk altid kører som root, men hvad med kommandolinjeværktøjer? Heldigvis understøttes dette også, forudsat at du har de rigtige værktøjer installeret. Hvis du bruger Ubuntu, skal du f.eks. bruge pakken libcap2-bin. Du skal også køre en ikke-arkaisk kerne (fra version 2.6.24).

Disse funktioner tillader, at tilladelser knyttes til eksekverbare filer, svarende til indstilling af SUID-bit, men kun for et specifikt sæt tilladelser. Utility setcap bruges til at tilføje og fjerne tilladelser fra en fil.

Det første trin er at vælge de tilladelser, du har brug for. Af hensyn til denne artikel antager jeg, at der er et netværksdiagnoseværktøj kaldet tracewalk, som burde kunne bruges rå fatninger. Dette kræver normalt, at applikationen køres som root, men når den vises listen det viser sig, at der kun kræves tilladelse CAP_NET_RAW.

Forudsat at du er i den mappe, hvor binæren er placeret tracewalk, kan du tilføje denne tilladelse sådan her:

sudo setcap cap_net_raw=eip tracewalk

Ignorer suffikset indtil videre =eip for løsning, vil jeg tale om det om et par sekunder. Bemærk, at tilladelsens navn er med små bogstaver. Du kan nu kontrollere, om du har konfigureret tilladelser korrekt med:

setcap -v cap_new_raw=eip tracewalk

Eller du kan liste alle tilladelser sat for en given eksekverbar:

getcap tracewalk

Til reference kan du også fjerne alle tilladelser fra den eksekverbare med:

setcap -r tracewalk

På dette tidspunkt bør du være i stand til at køre den eksekverbare bruger som en uprivilegeret bruger, og den skal kunne arbejde med rå sockets, men ikke have nogen af ​​de andre privilegier, som root-brugeren har.

Så hvad betyder dette mærkelige suffiks? =eip? Dette kræver en vis forståelse af karakteren af ​​tilladelser. Hver proces har tre sæt tilladelser − effektiv, arvelig og tilladt:

• Effektiv Tilladelser er dem, der definerer, hvad en proces faktisk kan gøre. For eksempel kan den ikke håndtere rå fatninger hvis CAP_NET_RAW er ikke i det effektive sæt.
• Ledig tilladelser er dem, som en proces må have, hvis den anmoder om dem ved hjælp af det relevante opkald. De forhindrer en proces i faktisk at gøre noget, medmindre den specifikt er skrevet for at anmode om nævnte tilladelse. Dette gør det muligt at skrive processer for kun at tilføje kritiske tilladelser til det effektive sæt for den periode, hvor de faktisk er nødvendige.
• Arvelig tilladelser er dem, der kan nedarves i det tilgængelige sæt af den affødte underordnede proces. Under operationen fork() eller clone() den underordnede proces får altid en kopi af den overordnede process tilladelser, da den stadig kører den samme eksekverbare på det tidspunkt. Et arveligt sæt bruges når exec() (eller tilsvarende) kaldes for at erstatte den eksekverbare fil med en anden. På dette tidspunkt maskeres processens tilgængelige sæt af det arvelige sæt for at opnå det tilgængelige sæt, der vil blive brugt til den nye proces.

Så nytten setcap giver os mulighed for at tilføje tilladelserne for disse tre sæt uafhængigt for en given eksekverbar. Bemærk, at betydningen af ​​grupper fortolkes lidt anderledes for filtilladelser:

• tilgængelig filtilladelser er dem, der altid er tilgængelige for en eksekverbar fil, selvom den overordnede proces, der kaldte den, ikke havde dem. De plejede at blive kaldt "tvangstilladelser".
• Nedarvet filtilladelser definerer en ekstra maske, der også kan bruges til at fjerne tilladelser fra opkaldsprocessens sæt. De gælder udover opkaldsprocessens nedarvede sæt, så tilladelsen nedarves kun, hvis den findes i begge sæt.
• Effektiv filtilladelser er faktisk kun en enkelt bit, ikke et sæt, og hvis de er indstillet, betyder det, at hele det tilgængelige sæt også kopieres ind i den nye process effektive sæt. Dette kan bruges til at tilføje tilladelser til processer, der ikke specifikt er skrevet for at anmode om dem. Da det er en bit, hvis du indstiller det til en tilladelse, skal det indstilles for alle tilladelser. Du kan tænke på det som en ældre bit, fordi det bruges til at tillade, at tilladelser bruges af programmer, der ikke understøtter dem.

Når du angiver tilladelser via setcap tre bogstaver e, i и p henvise til effektiv, arvelig og tilgængelig sæt hhv. Så den tidligere specifikation:

sudo setcap cap_net_raw=eip tracewalk

...angiver, at opløsningen CAP_NET_RAW skal tilføjes til de tilgængelige og arvelige sæt, og at den effektive bit også skal indstilles. Dette vil tilsidesætte alle tidligere indstillede tilladelser på filen. Brug en kommasepareret liste for at angive flere tilladelser på én gang:

sudo setcap cap_net_admin,cap_net_raw=eip tracewalk

Tilladelsesvejledning diskuterer alt dette mere detaljeret, men forhåbentlig har dette indlæg afmystificeret, hvad der foregår lidt. Der er kun nogle få forbehold og tricks tilbage at nævne.

For det første fungerer filfunktioner ikke med symbollinks - du skal anvende dem på selve den binære fil (dvs. målet for symbollinket).

For det andet fungerer de ikke med fortolkede scripts. For eksempel, hvis du har et Python-script, som du vil tildele tilladelse til, skal du tildele det til selve Python-fortolkeren. Dette er naturligvis et potentielt sikkerhedsproblem, for så vil alle scripts, der udføres med den fortolker, have den specificerede tilladelse, selvom dette stadig er væsentligt bedre end at gøre det til SUID. Den mest almindelige løsning ser ud til at være at skrive en separat eksekverbar i C eller tilsvarende, der kan udføre de nødvendige operationer og kalde den fra et script. Dette svarer til den tilgang, der bruges af Wireshark, som bruger en binær /usr/bin/dumpcap for at udføre privilegerede handlinger:

$ getcap /usr/bin/dumpcap 
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

For det tredje er filtilladelser deaktiveret, hvis du bruger en miljøvariabel LD_LIBRARY_PATH af åbenlyse sikkerhedsmæssige årsager(1). Det samme gælder for LD_PRELOAD, så vidt jeg ved.

1. Da en angriber åbenbart kan erstatte et af standardbibliotekerne og bruge LD_LIBRARY_PATHat tvinge dets bibliotek til at blive kaldt frem for systemet, og derfor få sin egen vilkårlige kode udført med de samme privilegier som den kaldende applikation.

Det er alt. Flere detaljer om kursusprogrammet kan findes på webinar, som finder sted den 24. januar.

Kilde: www.habr.com