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

A SUID, az SGID és a Sticky Bits hatékony speciális engedélyek, amelyeket beállíthat Linuxon futtatható fájlokhoz és könyvtárakhoz. Megosztjuk a használatuk előnyeit és lehetséges buktatóit.

Már használatban vannak

A biztonság többfelhasználós operációs rendszerbe való beépítése számos nehézséget rejt magában. Vegyük például a jelszavak (látszólag) alapfogalmát. Mindegyiket el kell tárolni, így minden 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, ezeket óvni kell.

Linuxon a tárolt jelszavak kétféleképpen védettek: titkosítottak, és csak root jogosultsággal rendelkezők férhetnek hozzá a jelszavakat tartalmazó fájlhoz. Ez jól hangzik, de egy kínos helyzetet jelent: Ha csak a root jogosultságokkal rendelkező emberek férhetnek hozzá a tárolt jelszavakhoz, hogyan változtathatják meg jelszavaikat azok, akik nem rendelkeznek ezzel a hozzáféréssel?

Állapotának emelése

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

Ideális lenne egy olyan séma, amelyben a rendszerben bárki elindíthatja a passwd programot, de a passwd program megtartja a root magasabb szintű jogosultságait. Ez bárkit feljogosít a saját jelszavának megváltoztatására.

A fenti forgatókönyv pontosan az, amit a Set User ID bit (SUID) csinál. Azt programokat és parancsokat futtat a fájl tulajdonosának engedélyével, nem pedig a programot elindító személy engedélyével.

Ön javítja a program státuszát

Van azonban egy másik nehézség is. Meg kell akadályozni, hogy a személy beavatkozzon bárki más jelszavába. A Linux magában foglalja a SUID sémát, amely lehetővé teszi alkalmazások futtatását ideiglenesen kölcsönzött engedélyekkel – de ez csak a fele a biztonsági történetnek.

Az a vezérlőmechanizmus, amely megakadályozza, hogy valaki egy másik személy jelszavával dolgozzon, a passwd programban található, nem az operációs rendszerben és a SUID-sémában.

Az emelt szintű jogosultságokkal futó programok biztonsági kockázatot jelenthetnek, ha nem a „beépített biztonság” gondolkodásmód szerint készültek. Ez azt jelenti, hogy a biztonság az első dolog, amit figyelembe kell venni, és csak azután építhet erre. Ne írja meg a programját, és utána próbáljon meg egy biztonsági réteget adni neki.

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

Ez az a kód, amely érzékeli, hogy valaki root-e.

  Mi az a Microsoft Editor, és hogyan használhatom?

Forráskód részlet innen

A következő példa egy példa, amelyben ezt figyelembe vették. Mivel a root bármilyen jelszót megváltoztathat, a programnak nem kell azokkal az ellenőrzésekkel bajlódnia, amelyeket általában azért végez, hogy megnézze, mely jelszavakat módosíthatja az adott személy. Tehát a root számára ez kihagyja ezeket az ellenőrzéseket, és kilép az ellenőrzés funkcióból.

Forráskód részlet innen

Az alapvető Linux-parancsokkal és segédprogramokkal biztos lehet benne, hogy biztonságot építettek beléjük, és a kódot sokszor felülvizsgálták. Természetesen mindig fennáll a még ismeretlen visszaélések veszélye. A javítások vagy frissítések azonban gyorsan megjelennek az újonnan azonosított biztonsági rések ellen.

Ez egy harmadik féltől származó szoftver – különösen minden, amely nem nyílt forráskódú –, rendkívül óvatosnak kell lennie a SUID használatával kapcsolatban. Nem azt mondjuk, hogy ne tedd, de ha igen, akkor meg akarsz győződni arról, hogy az nem teszi ki rendszerét kockázatnak. Nem akarja növelni egy olyan program jogosultságait, amely nem fogja megfelelően önkormányzni önmagát és az azt futtató személyt.

SUID-t használó Linux-parancsok

Az alábbiakban felsorolunk néhány olyan Linux-parancsot, amely a SUID bitet használja, hogy magasabb jogosultságokat adjon a parancsnak, ha 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

Vegye figyelembe, 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 engedélyeit általában három három karakterből álló csoport képviseli: rwx. Ezek az olvasást, írást és végrehajtást jelentik. Ha a levelek jelen vannak, az engedélyt megadták. Ha azonban betű helyett kötőjel (-) van, akkor ez az engedély nem adott.

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

Ha a SUID bit olyan fájlon van beállítva, amely nem rendelkezik végrehajtható képességekkel, akkor ezt egy nagy „S” betű jelöli.

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

passwd

A

A passwd parancs kéri dave-t az új jelszó megadására. Használhatjuk a ps parancsot a futó folyamatok részleteinek megtekintéséhez.

A ps-t használjuk a grep-pel egy másik terminálablakban és keresse meg a passwd folyamatot. A ps mellett az -e (minden folyamat) és -f (teljes formátum) opciót is használjuk.

A következő parancsot írjuk be:

ps -e -f | grep passwd

A

Két sor jelenik meg, amelyek közül a második a grep folyamat, amely a „passwd” karakterláncot tartalmazó parancsokat keresi. Ez az első sor, ami érdekel minket, mert ez az, amit a dave elindított passwd folyamatában.

Láthatjuk, hogy a passwd folyamat ugyanúgy fut, mint ha a root elindította volna.

  Hogyan lehet eltávolítani az említéseket a Twitterről

A SUID bit beállítása

A SUID bitet könnyű megváltoztatni a chmod segítségével. Az u+s szimbolikus mód beállítja a SUID bitet, az us szimbolikus mód pedig törli a SUID bitet.

A SUID bit néhány fogalmának illusztrálására létrehoztunk egy htg nevű kis programot. A dave felhasználó gyökérkönyvtárában van, és nincs beállítva a SUID bit. Amikor végrehajtja, megjeleníti a valós és érvényes felhasználói azonosítókat (UID).

Az igazi UID a programot elindító személyé. A tényleges azonosító az a fiók, amelynél a program úgy viselkedik, mintha elindította volna.

A következőket írjuk be:

ls -lh htg
./htg

A

Amikor a program helyi példányát futtatjuk, azt látjuk, hogy a valódi és a tényleges azonosítók egyaránt dave-re vannak állítva. Tehát úgy működik, ahogy egy normál programnak kell.

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

Beírjuk a következőket a chmod használatával a SUID bit beállításához, majd ellenőrizzük, hogy be van-e állítva:

sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg

A

Tehát a program átmásolódik, és a SUID bit be van állítva. Ismét lefuttatjuk, de ezúttal a /usr/local/bin mappában lévő másolatot fogjuk futtatni:

htg

A

Annak ellenére, hogy Dave elindította a programot, a tényleges azonosító a root felhasználóra van állítva. Tehát, ha Mary elindítja a programot, ugyanez történik, az alábbiak szerint:

htg

A

A valódi azonosító mária, a tényleges azonosító pedig a root. A program a root felhasználó engedélyével fut.

Az SGID bit

A Set Group ID (SGID) bit nagyon hasonló a SUID bithez. Ha az SGID bit be van állítva egy végrehajtható fájlon, akkor a tényleges csoport a fájl csoportja lesz. A folyamat a fájlcsoport tagjainak engedélyeivel fut, nem pedig a fájlt elindító személy engedélyeivel.

A htg programunkat úgy alakítottuk, hogy az is a hatékony csoportot mutassa. A htg program csoportját a mary felhasználó alapértelmezett csoportjára módosítjuk, maryra. Használjuk a us és g+s szimbolikus módokat is a chown-nal a SUID bit eltávolításához és az SGID beállításához.

Ehhez 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

Az SGID bitet „s”-vel jelölve láthatja a csoportengedélyekben. Azt is vegye figyelembe, hogy a csoport maryra van állítva, és a fájlnév most sárga színnel van kiemelve.

A program futtatása előtt határozzuk meg, hogy Dave és Mary mely csoportokhoz tartozik. Az id parancsot a -G (groups) opcióval együtt használjuk, az összes csoportazonosító kinyomtatásához. Ezután a htg programot dave néven futtatjuk.

A következő parancsokat írjuk be:

id -G dave
id -G mary
htg

A

A mary alapértelmezett csoportjának azonosítója 1001, a htg program tényleges csoportja pedig 1001. Tehát bár dave indította el, a mary csoport tagjainak engedélyével fut. Ez ugyanaz, mintha Dave csatlakozott volna a Mary csoporthoz.

Alkalmazzuk az SGID bitet egy könyvtárra. Először létrehozunk egy „work” nevű könyvtárat, majd módosítjuk a csoportját „geek”-re. Ezután beállítjuk az SGID bitet a könyvtárban.

  A JetBrains DataGrip telepítése Linuxra

Amikor az ls-t használjuk a könyvtár beállításainak ellenőrzésére, akkor a -d (könyvtár) opciót is használjuk, így a könyvtár részleteit látjuk, nem 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

Az SGID bit és a „geek” csoport be van állítva. Ezek hatással lesznek a munkakönyvtárban létrehozott elemekre.

A következőket írjuk be a munkakönyvtárba való belépéshez, létrehozunk egy „demo” nevű könyvtárat, és ellenőrizzük a tulajdonságait:

cd work
mkdir demo
ls -lh -d demo

A

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

Írjuk be a következőket egy fájl létrehozásához a érintés parancsot, és ellenőrizze a tulajdonságait:

touch useful.sh
ls -lh useful.sh

A

Az új fájl csoportja automatikusan „geek” lesz.

A ragadós bit

A ragadós bit nevét történelmi rendeltetéséről kapta. Amikor egy végrehajtható fájlra van beállítva, jelezte az operációs rendszernek, hogy a végrehajtható fájl szöveges részeit swapban kell tartani, így gyorsabbá válik az újrafelhasználás. Linuxon a ragadós bit csak egy könyvtárat érint – nem lenne értelme fájlon beállítani.

Ha beállítja a ragadó bitet egy könyvtárban, az emberek csak a hozzájuk tartozó fájlokat törölhetik a könyvtárban. Nem törölhetik azokat a fájlokat, amelyek valaki máshoz tartoznak, függetlenül attól, hogy a fájlengedélyek melyik kombinációja vannak beállítva a fájlokon.

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

Hozzunk létre egy „megosztott” nevű könyvtárat. Az o+t szimbolikus módot használjuk a chmod-dal, hogy beállítsuk a ragadós bitet az adott könyvtárban. Ezután megvizsgáljuk az adott könyvtár engedélyeit, valamint a /tmp és /var/tmp könyvtárakat.

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

A

Ha a ragadó bit be van állítva, akkor az „egyéb” fájlengedély-készlet végrehajtható bitje „t”-re van állítva. A fájl neve szintén kék színnel van kiemelve.

A /tmp és a /var/tmp mappa két példa azokra a könyvtárakra, amelyekben az összes fájljogosultság be van állítva a tulajdonos, a csoport és mások számára (ezért zölddel vannak kiemelve). Ezeket az ideiglenes fájlok megosztott helyeként használják.

Ezekkel az engedélyekkel elméletileg bárki bármit megtehet. A ragadós bit azonban felülírja őket, és senki nem törölheti a nem hozzá tartozó fájlt.

Emlékeztetők

Az alábbiakban egy gyors ellenőrzőlista található a fent leírtakkal kapcsolatban, későbbi hivatkozás céljából:

A SUID csak fájlokon működik.
Alkalmazhatja az SGID-t könyvtárakra és fájlokra.
A ragadó bitet csak a könyvtárakra használhatja.
Ha az „s”, „g“ vagy „t” jelzők nagybetűvel jelennek meg, akkor a végrehajtható bit (x) nincs beállítva.