Hur man använder SUID, SGID och Sticky Bits på Linux

• Dave McKay

  @TheGurkha

• 26 februari 2020, 8:00am EDT

SUID, SGID och Sticky Bits är kraftfulla specialbehörigheter som du kan ställa in för körbara filer och kataloger i Linux. Vi kommer att dela med oss av fördelarna – och potentiella fallgropar – med att använda dem.

De används redan

Att bygga in säkerhet i ett fleranvändaroperativsystem innebär flera dilemman. Ta till exempel det (till synes) grundläggande konceptet med lösenord. De måste lagras så att systemet varje gång någon loggar in kan jämföra det lösenord han skriver med den lagrade kopian. Eftersom lösenord är nycklarna till riket måste de naturligtvis skyddas.

På Linux skyddas lagrade lösenord på två sätt: de är krypterade och endast någon med root-privilegier kan komma åt filen som innehåller lösenorden. Det kan låta bra, men det skapar ett dilemma: Om bara personer med root-privilegier kan komma åt lagrade lösenord, hur ändrar de som inte har den åtkomsten sina lösenord?

Höjning av din status

I vanliga fall körs Linux-kommandon och -program med samma uppsättning behörigheter som den person som startar programmet. När root kör kommandot passwd för att ändra ett lösenord körs det med roots behörigheter. Det innebär att kommandot passwd har fri tillgång till de lagrade lösenorden i filen /etc/shadow.

Vad som skulle vara idealiskt är ett system där vem som helst på systemet kan starta programmet passwd, men där programmet passwd behåller roots förhöjda privilegier. Detta skulle göra det möjligt för vem som helst att ändra sitt eget lösenord.

Ovanstående scenario är precis vad biten Set User ID (SUID) gör. Den kör program och kommandon med filägarens behörigheter, snarare än behörigheterna för den person som startar programmet.

Du höjer programmets status

Det finns dock ett annat dilemma. Personen måste hindras från att lägga sig i någon annans lösenord. Linux innehåller SUID-schemat som gör det möjligt att köra program med en uppsättning tillfälligt lånade behörigheter – men det är bara halva säkerhetshistorien.

Kontrollmekanismen som hindrar någon från att arbeta med en annan persons lösenord finns i passwd-programmet, inte i operativsystemet och SUID-schemat.

Program som körs med förhöjda privilegier kan innebära säkerhetsrisker om de inte är skapade med ett ”security by design”-tänk. Det innebär att säkerheten är det första man tänker på och sedan bygger man på det. Skriv inte ditt program och försök sedan att ge det ett lager av säkerhet i efterhand.

Den största fördelen med programvara med öppen källkod är att du kan titta på källkoden själv eller hänvisa till betrodda peer-reviews av den. I källkoden för passwd-programmet finns det kontroller, så att du kan se om personen som kör programmet är root. Olika funktioner tillåts om någon är root (eller om någon använder sudo).

Detta är koden som upptäcker om någon är root.

Nedan följer ett exempel där hänsyn tas till detta. Eftersom root kan ändra vilket lösenord som helst behöver programmet inte bry sig om de kontroller som det vanligtvis utför för att se vilka lösenord personen har behörighet att ändra. Så för root hoppar det över dessa kontroller och avslutar kontrollfunktionen.

Med de centrala Linuxkommandona och -verktygen kan du vara säker på att de har säkerhet inbakad i sig och att koden har granskats många gånger. Naturligtvis finns det alltid hotet från ännu okända exploateringar. Det finns dock snabbt patchar eller uppdateringar för att motverka nyupptäckta sårbarheter.

Det är programvaror från tredje part – särskilt sådana som inte har öppen källkod – som du måste vara ytterst försiktig med att använda SUID med. Vi säger inte att du inte ska göra det, men om du gör det vill du försäkra dig om att det inte utsätter ditt system för risker. Du vill inte höja privilegierna för ett program som inte kommer att styra sig själv och den person som kör det på ett korrekt sätt.

Linuxkommandon som använder SUID

Nedan följer några av de Linuxkommandon som använder SUID-biten för att ge kommandot förhöjda privilegier när det körs av en vanlig användare:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Bemärk att filnamnen är markerade med rött, vilket indikerar att SUID-biten är satt.

Rättigheterna för en fil eller katalog representeras vanligtvis av tre grupper av tre tecken: rwx. Dessa står för read (läsa), write (skriva) och execute (utföra). Om bokstäverna finns med har den behörigheten beviljats. Om ett bindestreck (-) i stället för en bokstav finns med har dock den behörigheten inte getts.

Det finns tre grupper av dessa behörigheter (från vänster till höger): de för filens ägare, för medlemmar i filens grupp och för andra. När SUID-biten är inställd på en fil representerar ett ”s” ägarens exekveringsbehörighet.

Om SUID-biten är inställd på en fil som inte har exekveringsmöjligheter anger ett stort ”S” detta.

Vi ska ta en titt på ett exempel. Den vanliga användaren dave skriver kommandot passwd:

passwd

Kommandot passwd uppmanar dave att ange sitt nya lösenord. Vi kan använda kommandot ps för att se detaljer om processer som körs.

Vi använder ps med grep i ett annat terminalfönster och letar efter processen passwd. Vi använder också alternativen -e (varje process) och -f (fullständigt format) med ps.

Vi skriver följande kommando:

ps -e -f | grep passwd

Två rader rapporteras, varav den andra är grep-processen som letar efter kommandon med strängen ”passwd” i dem. Det är dock den första raden som intresserar oss, eftersom det är den för passwd-processen som dave startade.

Vi kan se att passwd-processen körs på samma sätt som den skulle ha gjort om root hade startat den.

Inställer SUID-biten

Det är enkelt att ändra SUID-biten med chmod. Det symboliska läget u+s ställer in SUID-biten och det symboliska läget u-s rensar SUID-biten.

För att illustrera några av koncepten för SUID-biten skapade vi ett litet program som heter htg. Det ligger i rotkatalogen för användaren dave och har inte SUID-biten inställd. När det exekveras visar det det verkliga och effektiva användar-ID (UID).

Det verkliga UID:t tillhör den person som startade programmet. Det effektiva ID:t är det konto som programmet beter sig som om det hade startats av.

Vi skriver följande:

ls -lh htg

./htg

När vi kör den lokala kopian av programmet ser vi att både det verkliga och det effektiva ID:t är satt till dave. Så det beter sig precis som ett normalt program ska göra.

Låt oss kopiera det till katalogen /usr/local/bin så att andra kan använda det.

Vi skriver följande, använder chmod för att sätta SUID-biten, och kontrollerar sedan att den har satts:

sudo cp htg /usr/local/bin

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

ls -hl /usr/local/bin/htg

Så, programmet är kopierat, och SUID-biten är satt. Vi kör det igen, men den här gången kör vi kopian i mappen /usr/local/bin:

htg

Även om dave startade programmet är det effektiva ID:t inställt på användaren root. Så om mary startar programmet händer samma sak, enligt nedan:

htg

Det riktiga ID:t är mary och det effektiva ID:t är root. Programmet körs med root-användarens behörigheter.

RELATERAT: Hur man använder kommandot chmod i Linux

Biten SGID

Biten Set Group ID (SGID) är mycket lik biten SUID. När SGID-biten sätts på en körbar fil sätts den effektiva gruppen till filens grupp. Processen körs med behörigheterna för medlemmarna i filens grupp, snarare än behörigheterna för den person som startade den.

Vi har justerat vårt htg-program så att det också visar den effektiva gruppen. Vi ändrar gruppen i programmet htg till att vara användaren marys standardgrupp, mary. Vi kommer också att använda de symboliska lägena u-s och g+s med chown för att ta bort biten SUID och ställa in SGID.

För att göra detta skriver vi följande:

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 att biten SGID betecknas av ”s” i gruppbehörigheterna. Observera också att gruppen är inställd på mary och att filnamnet nu är markerat med gult.

Innan vi kör programmet ska vi fastställa vilka grupper dave och mary tillhör. Vi använder kommandot id med alternativet -G (grupper) för att skriva ut alla grupp-ID:er. Sedan kör vi programmet htg som dave.

Vi skriver följande kommandon:

id -G dave

id -G mary

htg

ID:et för standardgruppen för mary är 1001, och den effektiva gruppen för programmet htg är 1001. Så även om det startades av dave körs det med behörigheter för medlemmarna i mary-gruppen. Det är samma sak som om dave hade gått med i gruppen mary.

Låt oss tillämpa SGID-biten på en katalog. Först skapar vi en katalog som heter ”work” och ändrar sedan dess grupp till ”geek”. Därefter ställer vi in SGID-biten på katalogen.

När vi använder ls för att kontrollera inställningarna för katalogen använder vi också alternativet -d (directory) så att vi ser detaljerna för katalogen, inte dess innehåll.

Vi skriver följande kommandon:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Biten SGID och gruppen ”geek” är inställda. Dessa påverkar alla objekt som skapas i katalogen work.

Vi skriver följande för att komma in i katalogen work, skapa en katalog som heter ”demo” och kontrollera dess egenskaper:

cd work

mkdir demo

ls -lh -d demo

Biten SGID och gruppen ”geek” tillämpas automatiskt på katalogen ”demo”.

Låt oss skriva följande för att skapa en fil med kommandot touch och kontrollera dess egenskaper:

touch useful.sh

ls -lh useful.sh

Gruppen för den nya filen sätts automatiskt till ”geek.”

RELATERAT: Hur man använder kommandot chown i Linux

The Sticky Bit

The sticky bit får sitt namn från sitt historiska syfte. När den sattes på en körbar fil markerade den för operativsystemet att textdelarna av den körbara filen skulle hållas i swap, vilket gjorde att de kunde återanvändas snabbare. På Linux påverkar den klibbiga biten endast en katalog – att ställa in den på en fil skulle inte vara meningsfullt.

När du ställer in den klibbiga biten på en katalog kan folk bara radera filer som tillhör dem inom den katalogen. De kan inte ta bort filer som tillhör någon annan, oavsett vilken kombination av filbehörigheter som är inställd på filerna.

Detta gör att du kan skapa en katalog som alla – och de processer de startar – kan använda som delad fillagring. Filerna är skyddade eftersom, återigen, ingen kan ta bort någon annans filer.

Låt oss skapa en katalog som heter ”shared”. Vi använder det symboliska läget o+t med chmod för att ställa in den klibbiga biten på den katalogen. Vi tittar sedan på behörigheterna för den katalogen samt katalogerna /tmp och /var/tmp.

Vi skriver följande kommandon:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Om den klibbiga biten är inställd sätts den exekverbara biten i den ”andra” uppsättningen av filbehörigheter till ”t”. Filnamnet är också markerat i blått.

Mapperna /tmp och /var/tmp är två exempel på kataloger där alla filbehörigheter är inställda för ägaren, gruppen och andra (det är därför de är markerade i grönt). De används som delade platser för tillfälliga filer.

Med dessa behörigheter borde vem som helst, i teorin, kunna göra vad som helst. Den klibbiga biten åsidosätter dem dock, och ingen kan ta bort en fil som inte tillhör honom eller henne.

Reminder

Nedan följer en snabb checklista över vad vi täckte ovan för framtida referens:

• SUID fungerar bara på filer.
• Du kan applicera SGID på kataloger och filer.
• Du kan bara tillämpa den klibbiga biten på kataloger.
• Om indikatorerna ”s”, ”g” eller ”t” visas med stora bokstäver har den exekverbara biten (x) inte ställts in.