SUID, SGID och Sticky Bits är kraftfulla specialbehörigheter som du kan ställa in för körbara filer och kataloger på Linux. Vi kommer att dela fördelarna – och potentiella fallgropar – med att använda dem.
Innehållsförteckning
De är redan i bruk
Att bygga in säkerhet i ett fleranvändaroperativsystem innebär flera problem. Ta det (till synes) grundläggande konceptet med lösenord, till exempel. De måste alla lagras så varje gång någon loggar in kan systemet jämföra lösenordet han skriver med den lagrade kopian. Uppenbarligen, eftersom lösenord är nycklarna till kungariket, måste de 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 är ett problem: Om bara personer med root-privilegier kan komma åt lagrade lösenord, hur ändrar de som inte har den tillgången sina lösenord?
Öka din status
Vanligtvis körs Linux-kommandon och -program med samma uppsättning behörigheter som personen som startar programmet. När root kör kommandot passwd för att ändra ett lösenord, den körs med roots behörigheter. Det betyder att kommandot passwd fritt kan komma åt de lagrade lösenorden i filen /etc/shadow.
Det som skulle vara idealiskt är ett schema där vem som helst i systemet kan starta passwd-programmet, men låta passwd-programmet behålla roots förhöjda privilegier. Detta skulle ge vem som helst möjlighet att ändra sitt eget lösenord.
Ovanstående scenario är exakt vad biten Set User ID (SUID) gör. den kör program och kommandon med tillstånd från filägaren, snarare än behörigheter från personen som startar programmet.
Du höjer programmets status
Det finns dock ett annat problem. Personen måste förhindras från att blanda sig i någon annans lösenord. Linux innehåller SUID-schemat som tillåter det att köra applikationer med en uppsättning tillfälligt lånade behörigheter – men det är bara hälften av säkerhetshistorien.
Kontrollmekanismen som hindrar någon från att arbeta med en annan persons lösenord finns i passwd-programmet, inte operativsystemet och SUID-schemat.
Program som körs med förhöjda privilegier kan utgöra säkerhetsrisker om de inte är skapade med ett ”security by design”-tänk. Det betyder att säkerhet är det första du tänker på, och sedan bygger du vidare på det. Skriv inte ditt program och försök sedan ge det en trygghet efteråt.
Den största fördelen med programvara med öppen källkod är du kan titta på källkoden själv eller hänvisa till betrodda referentgranskningar av det. I källkoden för passwd-programmet finns kontroller, så att du kan se om personen som kör programmet är root. Olika möjligheter är tillåtna om någon är root (eller någon som använder sudo).
Detta är koden som känner av om någon är root.
Följande är ett exempel där det tas hänsyn till. 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 tillstånd att ändra. Så, för root, det hoppar över dessa kontroller och avslutar kontrollfunktionen.
Med Linux-kommandon och kärnverktyg kan du vara säker på att de har säkerhet inbyggd i dem och att koden har granskats många gånger. Naturligtvis finns det alltid hot om ännu okända utnyttjande. Däremot dyker det upp snabbt patchar eller uppdateringar för att motverka eventuella nyligen identifierade sårbarheter.
Det är programvara från tredje part – särskilt alla som inte är öppen källkod – du måste vara extremt försiktig med att använda SUID med. Vi säger inte att du inte gör det, men om du gör det vill du vara säker på att det inte utsätter ditt system för risker. Du vill inte höja privilegierna för ett program som inte kommer att korrekt självstyra sig själv och personen som kör det.
Linux-kommandon som använder SUID
Följande är några av Linux-kommandona 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
Observera att filnamnen är markerade i rött, vilket indikerar att SUID-biten är inställd.
Behörigheterna för en fil eller katalog representeras vanligtvis av tre grupper med tre tecken: rwx. Dessa står för läsa, skriva och utföra. Om breven finns har det tillståndet beviljats. Om ett bindestreck (-) i stället för en bokstav är närvarande, har den tillståndet dock inte getts.
Det finns tre grupper av dessa behörigheter (från vänster till höger): de för ägaren av filen, 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 körbara funktioner, anger ett versaler ”S” detta.
Vi ska ta en titt på ett exempel. Vanlig användare 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 detaljerna om pågående processer.
Vi kommer att använda ps med grep i ett annat terminalfönster och leta efter passwd-processen. Vi kommer också att använda alternativen -e (varje process) och -f (fullformat) 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 den första raden som intresserar oss, eftersom det är den för passwd-processen som startade.
Vi kan se att passwd-processen körs på samma sätt som om root hade startat den.
Ställa in SUID-biten
Det är lätt att ändra SUID-biten med chmod. U+s-symbolläget ställer in SUID-biten och us-symbolläget rensar SUID-biten.
För att illustrera några av koncepten för SUID-biten skapade vi ett litet program som heter htg. Den finns i rotkatalogen för dave-användaren, och den har inte SUID-biten inställd. När det körs visar det verkliga och effektiva användar-ID:n (UID).
Den verkliga UID tillhör personen som startade programmet. Det effektiva ID:t är kontot 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 de verkliga och effektiva ID:n är inställda på dave. Så det fungerar precis som ett vanligt program ska.
Låt oss kopiera den till katalogen /usr/local/bin så att andra kan använda den.
Vi skriver följande, använder chmod för att ställa in SUID-biten och kontrollerar sedan att den är inställd:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Så programmet kopieras och SUID-biten är inställd. 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å root-användaren. Så om Mary startar programmet händer samma sak, som visas nedan:
htg
Det verkliga ID:t är mary, och det effektiva ID:t är root. Programmet körs med root-användarens behörigheter.
SGID-biten
Biten Set Group ID (SGID) är mycket lik SUID-biten. När SGID-biten är inställd 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 personen som startade den.
Vi anpassade vårt htg-program så att det också visar den effektiva gruppen. Vi kommer att ändra gruppen i htg-programmet till att vara användaren Marys standardgrupp, mary. Vi kommer också att använda us och g+s symboliska lägen med chown för att ta bort SUID-biten och ställa in SGID.
För att göra det 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 SGID-biten betecknad med ”s” i gruppbehörigheterna. Observera också att gruppen är inställd på mary och filnamnet är nu markerat i gult.
Innan vi kör programmet, låt oss 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:n. Sedan kör vi htg-programmet som dave.
Vi skriver följande kommandon:
id -G dave
id -G mary
htg
ID:t för standardgruppen för mary är 1001, och den effektiva gruppen för htg-programmet är 1001. Så även om det lanserades av dave, körs det med tillstånd från medlemmarna i mary-gruppen. Det är samma sak som om Dave hade gått med i marygruppen.
Låt oss tillämpa SGID-biten på en katalog. Först skapar vi en katalog som heter ”arbete” och ändrar sedan dess grupp till ”nörd.” Vi kommer sedan att ställa in SGID-biten på katalogen.
När vi använder ls för att kontrollera inställningarna för katalogen kommer vi också att använda alternativet -d (katalog) så att vi ser detaljerna i 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
SGID-biten och ”nördgruppen” är inställda. Dessa kommer att påverka alla objekt som skapas i arbetskatalogen.
Vi skriver följande för att komma in i arbetskatalogen, skapa en katalog som heter ”demo” och kontrollera dess egenskaper:
cd work
mkdir demo
ls -lh -d demo
SGID-biten och ”nördgruppen” appliceras automatiskt på ”demo”-katalogen.
Låt oss skriva följande för att skapa en fil med Rör kommando och kontrollera dess egenskaper:
touch useful.sh
ls -lh useful.sh
Gruppen för den nya filen ställs automatiskt in på ”nörd”.
Den klibbiga biten
Den klibbiga biten har fått sitt namn från sitt historiska syfte. När den var inställd på en körbar, flaggade den till operativsystemet att textdelarna av den körbara filen skulle bytas ut, vilket gör att de kan återanvändas snabbare. På Linux påverkar den klibbiga biten bara en katalog – att sätta den på en fil skulle inte vara meningsfullt.
När du ställer in den sticky biten på en katalog kan folk bara ta bort filer som tillhör dem i den katalogen. De kan inte ta bort filer som tillhör någon annan, oavsett vilken kombination av filbehörigheter som är inställda på filerna.
Detta låter dig skapa en katalog som alla – och de processer de startar – kan använda som delad fillagring. Filerna är skyddade eftersom, återigen, ingen kan radera någon annans filer.
Låt oss skapa en katalog som heter ”delad”. Vi använder det symboliska läget o+t med chmod för att ställa in sticky biten på den katalogen. Vi kommer sedan att titta på behörigheterna för den katalogen, såväl som 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 sticky biten är inställd, är den körbara biten för den ”andra” uppsättningen filbehörigheter inställd på ”t.” Filnamnet är också markerat i blått.
Mapparna /tmp och /var/tmp är två exempel på kataloger som har alla filbehörigheter 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 temporära filer.
Med dessa behörigheter borde vem som helst teoretiskt sett kunna göra vad som helst. Men den klibbiga biten åsidosätter dem, och ingen kan radera en fil som inte tillhör honom.
Påminnelser
Följande är en snabb checklista över vad vi täckte ovan för framtida referens:
SUID fungerar bara på filer.
Du kan tillämpa SGID på kataloger och filer.
Du kan bara använda den sticky biten på kataloger.
Om indikatorerna ”s”, ”g” eller ”t” visas med versaler, har den körbara biten (x) inte ställts in.