A SUID, SGID és a Sticky Bits használata Linuxon

• Dave McKay

  @TheGurkha

• Február 26, 2020, 8:00am EDT

A SUID, SGID és a Sticky Bits olyan hatékony speciális jogosultságok, amelyeket Linuxon a futtatható fájlok és könyvtárak számára állíthatunk be. Megosztjuk a használatukkal járó előnyöket – és a lehetséges buktatókat.

Már használatban vannak

A biztonság beépítése egy többfelhasználós operációs rendszerbe számos dilemmát vet fel. Vegyük például a jelszavak (látszólag) alapvető fogalmát. Ezeket mind el kell tárolni, hogy minden egyes alkalommal, amikor valaki bejelentkezik, a rendszer össze tudja hasonlítani az általa beírt jelszót a tárolt másolattal. Nyilvánvaló, hogy mivel a jelszavak a királyság kulcsai, meg kell védeni őket.

A Linuxon a tárolt jelszavak kétféleképpen vannak védve: titkosítva vannak, és csak az férhet hozzá a jelszavakat tartalmazó fájlhoz, aki root jogosultságokkal rendelkezik. Ez jól hangzik, de egy dilemmát vet fel: Ha csak a root jogosultságokkal rendelkező személyek férhetnek hozzá a tárolt jelszavakhoz, hogyan változtatják meg jelszavaikat azok, akiknek nincs ilyen hozzáférésük?

A státuszod emelése

A Linux-parancsok és programok általában ugyanazokkal a jogosultságokkal futnak, mint a programot indító személy. Amikor root a passwd parancsot futtatja a jelszó megváltoztatására, akkor az root jogosultságaival fut. Ez azt jelenti, hogy a passwd parancs szabadon hozzáférhet a /etc/shadow fájlban tárolt jelszavakhoz.

Az ideális az lenne, ha a rendszerben bárki elindíthatná a passwd programot, de a passwd program megtartaná a root megnövelt jogosultságait. Ez bárkit feljogosítana arra, hogy megváltoztassa a saját jelszavát.

A fenti forgatókönyv pontosan ezt teszi a Set User ID bit (SUID). A programokat és parancsokat a fájl tulajdonosának jogosultságaival futtatja, nem pedig annak a személynek a jogosultságaival, aki a programot elindítja.

Felemeli a program státuszát

Van azonban egy másik dilemma is. Meg kell akadályozni, hogy az illető beleavatkozzon más jelszavába. A Linux tartalmazza a SUID sémát, amely lehetővé teszi, hogy az alkalmazásokat ideiglenesen kölcsönzött jogosultságokkal futtassa – de ez csak a biztonsági történet egyik fele.

Az ellenőrzési mechanizmus, amely megakadályozza, hogy valaki más jelszavával dolgozzon, a passwd programban található, nem az operációs rendszerben és a SUID sémában.

A megemelt jogosultságokkal futó programok biztonsági kockázatot jelenthetnek, ha nem a “security by design” gondolkodásmóddal készülnek. Ez azt jelenti, hogy a biztonság az első dolog, amit figyelembe veszünk, majd erre építünk. Ne írja meg a programját, és ne csak utána próbálja meg biztonsággal felruházni.

A nyílt forráskódú szoftverek legnagyobb előnye, hogy a forráskódot saját maga is megnézheti, vagy hivatkozhat a forráskód megbízható, szakértői értékelésére. A passwd program forráskódjában vannak ellenőrzések, így láthatod, hogy a programot futtató személy root-e a root. Különböző képességek engedélyezettek, ha valaki root (vagy ha valaki sudo-t használ).

Ez az a kód, amely felismeri, hogy valaki root-e.

A következő egy példa, amelyben ezt figyelembe veszik. Mivel root bármilyen jelszót megváltoztathat, a programnak nem kell bajlódnia azokkal az ellenőrzésekkel, amelyeket általában elvégez annak megállapítására, hogy az illetőnek milyen jelszavak megváltoztatására van engedélye. Így a root esetében kihagyja ezeket az ellenőrzéseket, és kilép az ellenőrző funkcióból.

Az alapvető Linux-parancsok és segédprogramok esetében biztosak lehetünk abban, hogy a biztonságot beléjük sütötték, és hogy a kódot sokszor átnézték. Természetesen mindig fennáll a még ismeretlen exploitok veszélye. A javítások vagy frissítések azonban gyorsan megjelennek, hogy ellensúlyozzák az újonnan azonosított sebezhetőségeket.

A harmadik féltől származó szoftverekkel – különösen azokkal, amelyek nem nyílt forráskódúak – rendkívül óvatosan kell bánni SUID. Nem azt mondjuk, hogy ne tegye, de ha mégis megteszi, győződjön meg róla, hogy nem teszi ki a rendszerét kockázatnak. Nem akarod megnövelni egy olyan program jogosultságait, amely nem fogja magát és a futtatóját megfelelően önszabályozni.

Linux-parancsok, amelyek SUID-ot használnak

A következőkben néhány olyan Linux-parancsot mutatunk be, amelyek a SUID bitet használják, hogy a parancsnak megemelt jogosultságokat adjanak, amikor egy normál felhasználó futtatja:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Figyeljen arra, hogy a fájlnevek pirossal vannak kiemelve, ami azt jelzi, hogy a SUID bit be van állítva.

A fájl vagy könyvtár jogosultságait általában három három karakterből álló csoport képviseli: rwx. Ezek az olvasást, az írást és a végrehajtást jelentik. Ha a betűk jelen vannak, akkor az adott jogosultság meg van adva. Ha azonban betű helyett kötőjel (-) van jelen, akkor az adott engedélyt nem adták meg.

Ezeknek az engedélyeknek három csoportja van (balról jobbra haladva): a fájl tulajdonosának, a fájl csoportjának tagjainak és másoknak. Ha a SUID bit be van állítva egy fájlon, akkor egy “s” jelöli a tulajdonos execute engedélyét.

Ha a SUID bit be van állítva egy olyan fájlon, amely nem rendelkezik futtathatósággal, akkor egy nagybetűs “S” jelzi ezt.

Nézzünk egy példát. A normál felhasználó dave beírja a passwd parancsot:

passwd

A passwd parancs megkérdezi dave-tól az új jelszavát. A ps paranccsal megnézhetjük a futó folyamatok részleteit.

A ps parancsot a grep-vel egy másik terminálablakban használjuk, és megkeressük a passwd folyamatot. A ps mellett használjuk a -e (minden folyamat) és a -f (teljes formátum) opciókat is.

A következő parancsot írjuk be:

ps -e -f | grep passwd

Két sorban kapunk jelentést, a másodikban a grep folyamat olyan parancsokat keres, amelyekben a “passwd” karakterlánc szerepel. Minket azonban az első sor érdekel, mert az a dave által indított passwd folyamaté.

Láthatjuk, hogy a passwd folyamat ugyanúgy fut, mintha root indította volna el.

SUID bit beállítása

A SUID bitet könnyen megváltoztathatjuk a chmod segítségével. A u+s szimbolikus mód beállítja a SUID bitet, a u-s szimbolikus mód pedig törli a SUID bitet.

A SUID bit néhány fogalmának szemléltetésére készítettünk egy kis programot htg néven. Ez a dave felhasználó gyökérkönyvtárában van, és nincs beállítva a SUID bit. Amikor végrehajtjuk, megjeleníti a valódi és a tényleges felhasználói azonosítót (UID).

A valódi UID ahhoz a személyhez tartozik, aki a programot elindította. Az effektív azonosító az a fiók, amellyel a program úgy viselkedik, mintha a program indítója lett volna.

A következőket írjuk be:

ls -lh htg

./htg

Amikor a program helyi példányát futtatjuk, azt látjuk, hogy a valós és az effektív azonosító egyaránt dave. Tehát úgy viselkedik, ahogy egy normális programnak kellene.

Másoljuk át a /usr/local/bin könyvtárba, hogy mások is használhassák.

A következőket írjuk be, a chmod segítségével beállítjuk a SUID bitet, majd ellenőrizzük, hogy be lett-e állítva:

sudo cp htg /usr/local/bin

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

ls -hl /usr/local/bin/htg

A program tehát bemásolódott, és a SUID bit be lett állítva. Futtassuk le újra, de ezúttal a másolatot a /usr/local/bin mappában futtatjuk:

htg

Még ha dave indította is a programot, a tényleges azonosító a root felhasználóra van állítva. Tehát, ha mary indítja el a programot, ugyanez történik, az alábbiak szerint:

htg

A valódi azonosító mary, a tényleges azonosító pedig root. A program a root felhasználó jogosultságaival fut.

RELATED: Hogyan használjuk a chmod parancsot Linuxon

A SGID bit

A Set Group ID (SGID) bit nagyon hasonlít a SUID bithez. Amikor a SGID bit be van állítva egy futtatható fájlon, a tényleges csoport a fájl csoportjára van beállítva. A folyamat a fájl csoportjának tagjainak jogosultságaival fut, nem pedig annak a személynek a jogosultságaival, aki elindította.

A htg programunkat úgy állítottuk be, hogy a tényleges csoportot is megmutassa. A htg program csoportját a mary felhasználó mary alapértelmezett csoportjára, mary-re módosítjuk. A u-s és g+s szimbolikus módokat is használjuk a chown segítségével, hogy eltávolítsuk a SUID bitet és beállítsuk a SGID-t.

Ezért a következőket írjuk be:

sudo chown root:mary /usr/local/bin/htg

sudo chmod u-s,g+s /usr/local/bin/htg

ls -lh /usr/local/bin/htg

A csoportengedélyekben az SGID bitet az “s” jelöli. Figyeljük meg azt is, hogy a csoport mary lett beállítva, és a fájl neve most sárgával van kiemelve.

Mielőtt futtatnánk a programot, állapítsuk meg, hogy a dave és a mary melyik csoporthoz tartozik. Használjuk a id parancsot a -G (csoportok) opcióval, hogy kiírjuk az összes csoport azonosítóját. Ezután futtassuk a htg programot dave-ként.

A következő parancsokat írjuk be:

id -G dave

id -G mary

htg

A mary alapértelmezett csoport azonosítója 1001, a htg program tényleges csoportja pedig 1001. Tehát, bár a dave indította el, a mary csoport tagjainak jogosultságaival fut. Ez ugyanolyan, mintha dave csatlakozott volna a mary csoporthoz.

Alkalmazzuk a SGID bitet egy könyvtárra. Először létrehozunk egy “work” nevű könyvtárat, majd a csoportját “geek”-re változtatjuk. Ezután beállítjuk a SGID bitet a könyvtáron.

Amikor a ls segítségével ellenőrizzük a könyvtár beállításait, használjuk a -d (könyvtár) opciót is, hogy a könyvtár részleteit lássuk, ne a tartalmát.

A következő parancsokat írjuk be:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

A SGID bit és a “geek” csoport be van állítva. Ezek hatással lesznek a work könyvtárban létrehozott minden elemre.

A következőkkel lépünk be a work könyvtárba, létrehozunk egy “demo” nevű könyvtárat, és ellenőrizzük a tulajdonságait:

cd work

mkdir demo

ls -lh -d demo

A SGID bit és a “geek” csoport automatikusan alkalmazásra kerül a “demo” könyvtárban.

Az alábbiakat írjuk be, hogy létrehozzunk egy fájlt a touch paranccsal, és ellenőrizzük a tulajdonságait:

touch useful.sh

ls -lh useful.sh

Az új fájl csoportja automatikusan “geek”-re módosul: Hogyan használjuk a chown parancsot Linuxon

A ragadós bit

A ragadós bit a nevét történelmi céljáról kapta. Amikor egy futtatható fájlban be van állítva, jelezte az operációs rendszernek, hogy a futtatható fájl szöveges részeit a swapban kell tartani, így gyorsabbá téve azok újrafelhasználását. Linuxon a sticky bit csak egy könyvtárat érint – egy fájlra való beállításának nem lenne értelme.

Ha a sticky bitet egy könyvtárra állítjuk, akkor az emberek csak a hozzájuk tartozó fájlokat törölhetik az adott könyvtáron belül. Nem törölhetnek olyan fájlokat, amelyek máshoz tartoznak, függetlenül attól, hogy a fájljogosultságok milyen kombinációja van beállítva a fájlokra.

Ez lehetővé teszi egy olyan könyvtár létrehozását, amelyet mindenki – és az általuk indított folyamatok – közös fájltárolóként használhatnak. A fájlok védettek, mert megint csak senki sem törölheti más fájljait.

Hozzunk létre egy “shared” nevű könyvtárat. Használjuk a o+t szimbolikus módot a chmod segítségével, hogy beállítsuk a sticky bitet ebben a könyvtárban. Ezután megnézzük ennek a könyvtárnak, valamint a /tmp és /var/tmp könyvtáraknak az engedélyeit.

A következő parancsokat írjuk be:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Ha a sticky bit be van állítva, akkor az “egyéb” fájlengedélyek “t”-re állítják a futtatható bitet. A fájl neve szintén kékkel van kiemelve.

A /tmp és /var/tmp mappák két példa olyan könyvtárakra, amelyekben a tulajdonos, a csoport és az egyebek összes fájlengedélye be van állítva (ezért vannak zölddel kiemelve). Ezeket az ideiglenes fájlok megosztott helyeként használják.

Ezekkel a jogosultságokkal elméletileg bárki bármit megtehet. A ragadós bit azonban felülírja őket, és senki sem törölhet olyan fájlt, ami nem az övé.

Emlékezések

A következőkben egy gyors ellenőrző lista következik a fentiekben tárgyaltakról a későbbi tájékozódás érdekében:

• SUID csak fájlokra működik.
• A SGID-t könyvtárakra és fájlokra is alkalmazhatod.
• A sticky bitet csak könyvtárakra alkalmazhatod.
• Ha a “s“, “g” vagy “t” jelzők nagybetűvel jelennek meg, akkor a futtatható bit (x) nem lett beállítva.