SUID, SGID och Sticky Bits är avancerade behörigheter som kan tillämpas på körbara filer och kataloger inom Linux-system. Denna genomgång belyser nyttan och potentiella risker med deras användning.
Väl Etablerade i Användning
Integrering av säkerhetsmekanismer i ett operativsystem med flera användare medför en rad utmaningar. Ta till exempel den grundläggande funktionen för lösenordshantering. Lösenord måste lagras på ett säkert sätt, så att systemet kan verifiera inloggningar genom att jämföra angivna lösenord med de lagrade versionerna. Det är viktigt att lösenord skyddas, eftersom de utgör nyckeln till systemets säkerhet.
I Linux lagras lösenord krypterade och i en fil som endast kan nås av användare med root-behörighet. Även om detta låter säkert, finns ett problem. Om endast root-användare har behörighet att se lagrade lösenord, hur kan användare utan root-privilegier ändra sina lösenord?
Öka Dina Rättigheter
I vanliga fall körs Linux-kommandon och program med samma behörigheter som användaren som startade processen. När root-användaren kör kommandot passwd för att ändra ett lösenord, utförs det med root-behörigheter. Detta ger kommandot passwd tillgång till lagrade lösenord i /etc/shadow-filen.
En idealisk lösning skulle vara ett system där vem som helst kan köra passwd-programmet, samtidigt som programmet behåller root-behörighet. Detta skulle göra det möjligt för alla användare att ändra sina egna lösenord.
Detta scenario är precis vad ”Set User ID” (SUID)-biten åstadkommer. Den gör det möjligt att köra program och kommandon med ägarens behörighet, snarare än den som initierade programmet.
Programmets Utökade Behörigheter
Det uppstår emellertid ett annat problem. Systemet måste förhindra att en användare manipulerar en annan användares lösenord. Linux har implementerat SUID-systemet som tillåter körning av applikationer med tillfälligt utökade behörigheter, men detta är bara en del av den komplexa säkerhetsberättelsen.
Den kontrollmekanism som hindrar användare från att ändra andras lösenord finns i passwd-programmet, inte i själva operativsystemet eller SUID-schemat.
Program som körs med utökade privilegier kan vara en säkerhetsrisk om de inte är konstruerade med säkerhet i åtanke. Säkerhet bör prioriteras under utvecklingsprocessen och inte ses som en eftertanke.
En fördel med öppen källkod är att du har möjlighet att granska källkoden eller ta del av granskningar från betrodda källor. I passwd-programmets källkod finns mekanismer som kontrollerar om användaren är root. Beroende på om användaren är root (eller använder sudo), tillåts olika åtgärder.
Denna kod avgör om användaren är root.
Följande är ett exempel på hur detta implementeras: Eftersom en root-användare kan ändra vilket lösenord som helst, behöver programmet inte utföra sina vanliga kontroller för att bestämma vilka lösenord användaren har rätt att ändra. Därför hoppar den över dessa kontroller och lämnar kontrollfunktionen.
När det gäller Linux-kommandon och grundläggande verktyg kan du vara säker på att säkerhet är en integrerad del av dem och att koden är granskad. Dock finns det alltid en risk för okända exploateringar. Men oftast släpps patchar och uppdateringar snabbt för att åtgärda potentiella sårbarheter.
Man bör vara försiktig med SUID vid användning av program från tredje part, speciellt de som inte är öppen källkod. Vi säger inte att det ska undvikas, men det är viktigt att du säkerställer att systemet inte utsätts för risker. Undvik att utöka privilegier för program som inte kan övervaka sina egna handlingar.
Linux-kommandon med SUID
Här är några Linux-kommandon som använder SUID-biten för att ge utökade privilegier när de körs av vanliga användare:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Filnamnen är markerade i rött, vilket indikerar att SUID-biten är inställd.
Behörigheterna för filer och kataloger representeras ofta av tre grupper om tre tecken, rwx (läsa, skriva, utföra). Om en bokstav visas, ges behörigheten. Om ett bindestreck (-) istället för en bokstav visas, ges inte behörigheten. Det finns tre grupper av dessa behörigheter (från vänster till höger): för filens ägare, för medlemmarna 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 saknar körbara funktioner, kommer ett versalt ”S” visa detta.
Låt oss titta på ett exempel: En vanlig användare, dave, skriver kommandot passwd:
passwd
Kommandot passwd uppmanar dave att ange sitt nya lösenord. Detaljer om processer kan ses med hjälp av kommandot ps, för att visa detaljer om pågående processer.
Genom att använda ps tillsammans med grep i ett annat terminalfönster kan vi söka efter passwd-processen. Vi använder också alternativen -e (varje process) och -f (fullformat) med ps.
Vi skriver följande kommando:
ps -e -f | grep passwd
Två rader visas, varav den andra är grep-processen som söker efter kommandon med strängen ”passwd”. Den första raden är av intresse, eftersom den är processen för passwd som startades.
Vi kan se att passwd-processen körs på samma sätt som om den hade startats av root.
Aktivera SUID-biten
Det är enkelt att ändra SUID-biten med chmod. Läget U+s aktiverar SUID-biten och läget u-s avaktiverar SUID-biten.
För att illustrera SUID-bitens funktion, har vi skapat ett program som heter htg. Det finns i root-katalogen för dave-användaren och SUID-biten är inte aktiv. När programmet körs, visar det de riktiga och effektiva användar-ID:na (UID).
Det riktiga UID:t tillhör den användare som startade programmet. Det effektiva UID:t är kontot som programmet utförs 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 de riktiga och effektiva UID:na är inställda på dave. Det fungerar som förväntat.
Låt oss kopiera det till mappen /usr/local/bin, så att andra kan använda det.
Vi skriver följande, använder chmod för att ställa in SUID-biten och kontrollerar sedan att den har aktiverats:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Nu är programmet kopierat och SUID-biten inställd. Vi kör det igen, men nu kör vi kopian från /usr/local/bin-mappen:
htg
Även om dave startade programmet, är det effektiva ID:t inställt till root-användaren. Om Mary kör programmet, händer samma sak, som visas nedan:
htg
Det riktiga ID:t är mary, och det effektiva ID:t är root. Programmet körs med root-användarens behörighet.
SGID-biten
Set Group ID (SGID)-biten är snarlik SUID-biten. När SGID-biten är inställd på en körbar fil, ställs den effektiva gruppen in till filens grupp. Processen körs med behörigheter för medlemmarna i filens grupp, snarare än den som startade den.
Vi har uppdaterat vårt htg-program för att visa den effektiva gruppen. Vi ändrar gruppen för htg-programmet till marys standardgrupp. Vi använder de symboliska lägena us och g+s med chown för att ta bort SUID-biten och aktivera 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
SGID-biten visas med ett ”s” i gruppbehörigheterna. Gruppen är inställd till mary och filnamnet är markerat i gult.
Innan vi kör programmet, låt oss bestämma vilka grupper dave och mary tillhör. Vi använder kommandot id med alternativet -G (grupper) för att visa alla grupp-ID:n. Sedan kör vi htg-programmet som dave.
Vi skriver följande kommandon:
id -G dave
id -G mary
htg
Marys standardgrupps ID är 1001 och den effektiva gruppen för htg-programmet är 1001. Trots att det startades av dave, körs programmet med behörigheter från medlemmarna i mary-gruppen. Det är samma sak som om dave hade gått med i mary-gruppen.
Låt oss aktivera SGID-biten på en katalog. Först skapar vi en katalog ”arbete” och ändrar dess grupp till ”nörd”. Sedan ställer vi in SGID-biten på katalogen.
När vi använder ls för att kontrollera katalogens inställningar, använder vi också alternativet -d (katalog), så att vi får detaljer om katalogen och 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
SGID-biten och gruppen ”nörd” är inställda. Dessa kommer att påverka objekt som skapas i katalogen ”arbete”.
Vi skriver följande för att gå in i arbetskatalogen, skapa katalogen ”demo” och kontrollera dess egenskaper:
cd work
mkdir demo
ls -lh -d demo
SGID-biten och gruppen ”nörd” tillämpas automatiskt på ”demo”-katalogen.
Vi skriver följande för att skapa en fil med touch och kontrollerar dess egenskaper:
touch useful.sh
ls -lh useful.sh
Gruppen för den nya filen är automatiskt inställd på ”nörd”.
Sticky Bit
Sticky biten har sitt namn från sin historiska användning. När den var aktiverad på en körbar fil, flaggade den operativsystemet att textdelarna i den körbara filen skulle lagras i minnet, vilket möjliggjorde snabbare återanvändning. I Linux påverkar sticky biten endast kataloger – att använda den på en fil skulle inte vara meningsfullt.
När du ställer in sticky biten på en katalog, kan användarna endast ta bort filer som tillhör dem i den katalogen. De kan inte ta bort filer som tillhör andra, oavsett vilka filbehörigheter som är inställda på filerna.
Detta gör det möjligt att skapa en katalog som alla – och de processer de startar – kan använda som en delad fillagring. Filer skyddas då ingen kan radera någon annans filer.
Låt oss skapa en katalog ”delad”. Vi använder det symboliska läget o+t med chmod för att aktivera sticky biten på den katalogen. Vi undersöker sedan behörigheterna för katalogen, såväl som /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 sticky biten är aktiverad är körbarhetsbiten för den ”andra” uppsättningen filbehörigheter inställd på ”t”. Filnamnet är också markerat i blått.
/tmp- och /var/tmp-mapparna är två exempel på kataloger med alla filbehörigheter aktiverade för ägaren, gruppen och andra (därför är de markerade i grönt). De används som delade platser för temporära filer.
Teoretiskt sett skulle detta innebära att alla kan göra vad som helst. Men sticky biten åsidosätter detta, och ingen kan radera en fil som inte tillhör dem.
Sammanfattning
Följande är en kort sammanfattning av det vi täckt, för framtida referens:
SUID fungerar endast på filer.
Du kan använda SGID på kataloger och filer.
Du kan endast använda sticky biten på kataloger.
Om indikatorerna ”s”, ”g” eller ”t” visas med versaler, är körbarhetsbiten (x) inte aktiverad.