Filrettigheter i Linux

Hei alle sammen. Vi er i gang med arbeidet og forbereder mange kraftige lanseringer allerede i januar. Blant annet har vi annonsert oppstart av et nytt kull av den populære kursen. «Linux-administrator». I forkant av lanseringen deler vi tradisjonelt oversettelsen av nyttig materiale.

Filrettigheter tilbyr et sikkert alternativ til SUID-kjørbare filer, men kan virke litt forvirrende ved første øyekast.

Vi vet alle at binære filer SUID er er en dårlig løsning sett fra et sikkerhetssynspunkt.. Heldigvis finnes det en mer effektiv måte hvis applikasjonen din trenger noe begrensede privilegier, kjent som filrettigheter..

Jeg vil spare deg for tid hvis du ønsker å unngå en detaljert gjennomlesning av artikkelen ovenfor: i essens tillater filrettigheter prosesser som kjøres på vegne av root-brukeren og som derfor har rett til å gjøre hva som helst, å beholde visse muligheter, begrenset til denne listen, når de senker privilegiene og kjører som en ikke-privilegert bruker. Dette betyr at hvis en angriper klarer å kompromittere prosessen ved hjelp av en buffer-overflow eller et annet utnyttelse, så vil de ikke kunne utnytte noe annet enn de bestemte minimale privilegiene som prosessen faktisk trenger.

Rettigheter passer godt for tjenester som vanligvis alltid kjører på vegne av root-brukeren, men hva med kommandolinjeverktøy? Heldigvis støttes dette også, forutsatt at du har de riktige verktøyene installert. Hvis du bruker Ubuntu, for eksempel, trenger du pakken libcap2-bin. Du må også bruke et moderne kjernestyresystem (fra versjon 2.6.24).

). Disse funksjonene lar deg knytte rettigheter til utførbare filer på samme måte som du konfigurerer SUID-biten, men kun for et bestemt sett av rettigheter. Verktøyet setcap brukes til å legge til og fjerne rettigheter fra en fil.

Det første steget er å velge de rettighetene du trenger. For denne artikkelen antar jeg at det finnes et nettverksdiagnoseverktøy kalt tracewalk, som skal kunne bruke rå sokler.Vanligvis krever dette at applikasjonen kjøres på vegne av root-brukeren, men når man ser på listen , viser det seg at det bare kreves rettighetene CAP_NET_RAW..

Forutsett at du er i katalogen hvor den binære filen ligger, tracewalkkan du legge til denne tillatelsen på følgende måte:

sudo setcap cap_net_raw=eip tracewalk

Ignorer suffikset =eip for tillatelsen, jeg skal forklare dette om et øyeblikk. Legg merke til at navnet på tillatelsen er skrevet med små bokstaver. Nå kan du sjekke om du har konfigurert tillatelsene riktig, med:

setcap -v cap_new_raw=eip tracewalk

Eller du kan liste opp alle tillatelsene som er satt for den aktuelle kjørbare filen:

getcap tracewalk

Til referanse kan du også fjerne alle tillatelser fra den kjørbare filen med:

setcap -r tracewalk

På dette tidspunktet skal du kunne kjøre den kjørbare filen som en ikke-privilegert bruker, og den skal kunne håndtere rå sokler, men ikke ha noen andre privilegier som root-brukeren har.

Så hva betyr dette merkelige suffikset =eip? Здесь потребуется толика понимания природы разрешений. Каждый процесс имеет три набора разрешений — effektive, arvelige og tillatte (effective, inheritable og permitted):

• Effektive tillatelser er de som bestemmer hva prosessen faktisk kan gjøre. For eksempel kan den ikke håndtere rå sokler hvis CAP_NET_RAW. den ikke er en del av det effektive settet.
• Tillatte tillatelser er de som det er tillatt for prosessen å ha, hvis den ber om dem med det aktuelle kallet. De tillater ikke prosessen faktisk å gjøre noe, med mindre den er spesifikt skrevet for å be om den angitte tillatelsen. Dette gjør det mulig å skrive prosesser for å legge til spesielt viktige tillatelser i det effektive settet bare i den perioden de faktisk er nødvendige.
• Arvelige tillatelser er de som kan arves i det tilgjengelige settet til den opprettede underprosessen. Under operasjonen fork() eller clone() får underprosessen alltid en kopi av tillatelsene til forelderen, siden den på dette punktet fortsatt kjører den samme kjørbare filen. Det arvelige settet brukes når exec() (eller lignende) blir kalt for å erstatte den kjørbare filen med en annen. På dette punktet skjules det tilgjengelige settet til prosessen av det arvelige settet for å få det tilgjengelige settet som skal brukes for den nye prosessen.

Dermed verktøyet setcap lar oss tillate oss å legge til tillatelser for disse tre sett uavhengig for denne eksekverbare filen. Merk at verdien av grupper tolkes litt forskjellig for tilgangsrettigheter til filer:

• Tilgjengelige filtillatelser er de som alltid er tilgjengelige for den eksekverbare filen, selv om forelderen som kalte den ikke hadde dem. Tidligere ble de kalt «tvangstilatelser».
• Arvede filtillatelser definerer et ekstra mask som også kan brukes til å fjerne tilganger fra settet tilkalleren. De brukes i tillegg til den arvede settet tilkalleren, så tillatelse arves bare hvis den finnes i begge sett.
• Effektive filtillatelser er faktisk bare et enkelt bit, ikke et sett, og hvis det er satt, betyr det at hele det tilgjengelige settet også kopieres til det effektive settet til den nye prosessen. Dette kan brukes til å legge til tilganger til prosesser som ikke spesielt er skrevet for å be om dem. Siden dette er et enkelt bit, hvis du setter det for noen tilgang, må det settes for alle tilganger. Du kan tenke på det som et legacy-bit, fordi det brukes for å tillate bruk av tillatelser for applikasjoner som ikke støtter dem.

Når du angir tillatelser gjennom setcap tre bokstaver e, i og p tilknyttet effektiv, arvet og tilgjengelig sett henholdsvis. Så, den tidligere spesifikasjonen:

sudo setcap cap_net_raw=eip tracewalk

… angir at retten CAP_NET_RAW. må legges til de tilgjengelige og arvede settene, og at den effektive bit også må settes. Dette vil erstatte eventuelle tidligere satte tillatelser i filen. For å sette flere tillatelser samtidig, bruk en liste med komma:

sudo setcap cap_net_admin,cap_net_raw=eip tracewalk

Veiledning om tillatelser diskuterer alt dette mer detaljert, men forhåpentligvis har dette innlegget avmystifisert hva som skjer litt. Det gjenstår bare å nevne noen advarsler og feller.

For det første fungerer ikke filmuligheter med symboliske lenker — du må anvende dem på den binære filen selv (det vil si målet for den symboliske lenken).

For det andre, de arbeider ikke med tolkede skript. For eksempel, hvis du har et Python-skript som du ønsker å tildele tillatelser, må du tildele det til Python-tolkeren selv. Dette er åpenbart et potensielt sikkerhetsproblem, fordi da vil alle skript som kjøres med denne tolken ha de angitte tillatelsene, selv om det fortsatt er betydelig bedre enn å bruke SUID. Den mest vanlige omveien ser ut til å være å skrive en egen kjørbar fil i C eller lignende, som kan utføre de nødvendige operasjonene og kalle den fra skriptet. Dette ligner tilnærmingen brukt av Wireshark, som bruker en binærfil. /usr/bin/dumpcap for å utføre privilegerte operasjoner:

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

For det tredje, filrettigheter deaktiveres hvis du bruker en miljøvariabel LD_LIBRARY_PATH av åpenbare sikkerhetsgrunner.(1)Det samme gjelder for LD_PRELOAD, så langt jeg vet.

1. Fordi en angriper tydeligvis kan erstatte et av de standardbibliotekene og bruke LD_LIBRARY_PATH, for å få sitt bibliotek til å bli kalt i stedet for systembiblioteket, og dermed ha sin egen vilkårlige kode som kjøres med de samme privilegiene som det påkallende programmet.

Det er alt. Mer informasjon om kursprogrammet vil være tilgjengelig på webinaret som finner sted 24. januar.

Kilde: habr.com