SUID, SGID и Sticky Bits са мощни специални разрешения, които можете да зададете за изпълними файлове и директории в Linux. Ще споделим ползите — и потенциалните клопки — от използването им.
Съдържание
Те вече се използват
Изграждането на сигурност в многопотребителска операционна система представлява няколко затруднения. Вземете например (привидно) основната концепция за пароли. Всички те трябва да бъдат съхранени, така че всеки път, когато някой влезе, системата може да сравни въведената от него парола със съхраненото копие. Очевидно, тъй като паролите са ключовете към кралството, те трябва да бъдат защитени.
В Linux съхранените пароли са защитени по два начина: те са криптирани и само някой с root привилегии има достъп до файла, който съдържа паролите. Това може да звучи добре, но представлява затруднение: Ако само хората с root привилегии имат достъп до съхранените пароли, как тези, които нямат такъв достъп, променят паролите си?
Повишаване на вашия статус
Обикновено командите и програмите на Linux работят със същия набор от разрешения като лицето, което стартира програмата. Когато root стартира командата passwd за да промените парола, той работи с правата на root. Това означава, че командата passwd има свободен достъп до съхранените пароли във файла /etc/shadow.
Това, което би било идеално, е схема, при която всеки в системата може да стартира програмата passwd, но програмата passwd да запази повишените привилегии на root. Това ще даде възможност на всеки да промени собствената си парола.
Горният сценарий е точно това, което прави битът Set User ID (SUID). То изпълнява програми и команди с разрешенията на собственика на файла, а не с разрешенията на лицето, което стартира програмата.
Вие повишавате статуса на програмата
Има обаче още едно затруднение. Лицето трябва да бъде предотвратено да се намесва с паролата на някой друг. Linux включва SUID схемата, която му позволява да стартира приложения с набор от временно заети разрешения — но това е само половината от историята на сигурността.
Механизмът за управление, който не позволява на някой да работи с паролата на друг човек, се съдържа в програмата passwd, а не в операционната система и SUID схемата.
Програмите, които се изпълняват с повишени привилегии, могат да представляват рискове за сигурността, ако не са създадени с начин на мислене „сигурност по дизайн“. Това означава, че сигурността е първото нещо, което имате предвид и след това надграждате върху това. Не пишете програмата си и след това се опитайте да й дадете слой сигурност.
Най-голямото предимство на софтуера с отворен код е можете сами да разгледате изходния код или се обърнете към доверени партньорски рецензии за него. В изходния код на програмата passwd има проверки, така че можете да видите дали лицето, което изпълнява програмата, е root. Разрешени са различни възможности, ако някой е root (или някой използва sudo).
Това е кодът, който открива дали някой е root.
Следва пример, в който това е взето предвид. Тъй като root може да промени всяка парола, програмата не трябва да се занимава с проверките, които обикновено извършва, за да види кои пароли има промяна на разрешението на лицето. Така че, за root, то пропуска тези проверки и излиза от функцията за проверка.
С основните команди и помощни програми на Linux можете да сте уверени, че имат вградена сигурност и че кодът е преглеждан много пъти. Разбира се, винаги има заплаха от все още неизвестни подвизи. Въпреки това бързо се появяват корекции или актуализации, за да противодействат на всички новооткрити уязвимости.
Това е софтуер на трети страни – особено всеки, който не е с отворен код – трябва да бъдете изключително внимателни при използването на SUID. Не казваме да не го правите, но ако го направите, искате да сте сигурни, че няма да изложи вашата система на риск. Вие не искате да повишавате привилегиите на програма, която няма да се самоуправлява правилно и лицето, което я изпълнява.
Linux команди, които използват SUID
Следват няколко от командите на Linux, които използват бит SUID, за да дадат на командата повишени привилегии, когато се изпълняват от обикновен потребител:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Обърнете внимание, че имената на файловете са маркирани в червено, което показва, че битът SUID е зададен.
Разрешенията за файл или директория обикновено са представени от три групи от три знака: rwx. Те означават четене, писане и изпълнение. Ако писмата са налице, това разрешение е дадено. Ако има тире (-) вместо буква обаче, това разрешение не е дадено.
Има три групи от тези разрешения (отляво надясно): тези за собственика на файла, за членовете на групата на файла и за други. Когато SUID битът е зададен на файл, „s“ представлява разрешението за изпълнение на собственика.
Ако битът SUID е зададен на файл, който няма изпълними възможности, главният букв „S“ означава това.
Ще разгледаме един пример. Редовният потребител dave въвежда командата passwd:
passwd
Командата passwd подканва на Дейв за новата му парола. Можем да използваме командата ps за да видите подробностите за изпълняваните процеси.
Ще използваме ps с grep в друг прозорец на терминала и потърсете процеса passwd. Ще използваме и опциите -e (всеки процес) и -f (пълен формат) с ps.
Набираме следната команда:
ps -e -f | grep passwd
Отчитат се два реда, вторият от които е grep процесът, който търси команди с низа „passwd“ в тях. Това е първият ред, който ни интересува обаче, защото това е този за процеса passwd, който Dave стартира.
Можем да видим, че процесът passwd работи по същия начин, както би, ако root го беше стартирал.
Задаване на бит SUID
Лесно е да промените SUID бита с chmod. Символичният режим u+s задава SUID бита, а символичният режим на US изчиства бита SUID.
За да илюстрираме някои от концепциите на бита SUID, създадохме малка програма, наречена htg. Той е в основната директория на потребителя dave и няма зададен бит SUID. Когато се изпълни, той показва реалните и ефективни потребителски идентификатори (UID).
Истинският UID принадлежи на лицето, стартирало програмата. Ефективният идентификатор е акаунтът, от който програмата се държи така, сякаш е била стартирана.
Пишем следното:
ls -lh htg
./htg
Когато стартираме локалното копие на програмата, виждаме, че реалните и ефективни идентификатори са зададени на dave. Така че, той се държи точно както трябва да бъде нормална програма.
Нека го копираме в директорията /usr/local/bin, за да могат другите да го използват.
Въведем следното, използвайки chmod, за да зададем SUID бита и след това проверяваме дали е зададен:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
И така, програмата се копира и битът SUID е зададен. Ще го стартираме отново, но този път ще стартираме копието в папката /usr/local/bin:
htg
Въпреки че Dave стартира програмата, ефективният идентификатор е зададен на root потребител. Така че, ако Мери стартира програмата, се случва същото, както е показано по-долу:
htg
Истинският ID е mary, а ефективният ID е root. Програмата работи с разрешенията на root потребителя.
Битът SGID
Битът Set Group ID (SGID) е много подобен на бита SUID. Когато SGID битът е зададен на изпълним файл, ефективната група се задава на групата на файла. Процесът се изпълнява с разрешенията на членовете на групата на файла, а не с разрешенията на лицето, което го е стартирало.
Настроихме нашата htg програма, така че да показва и ефективната група. Ще променим групата на програмата htg да бъде групата по подразбиране на потребителя на mary, mary. Също така ще използваме символичните режими us и g+s с chown, за да премахнем SUID бита и да зададем SGID.
За целта набираме следното:
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, обозначен с „s“ в разрешенията на групата. Също така имайте предвид, че групата е настроена на mary и името на файла вече е маркирано в жълто.
Преди да стартираме програмата, нека установим към кои групи принадлежат Дейв и Мери. Ще използваме командата id с опцията -G (групи), за да отпечатате всички групови идентификатори. След това ще стартираме програмата htg като Dave.
Въведем следните команди:
id -G dave
id -G mary
htg
Идентификаторът на групата по подразбиране за mary е 1001, а ефективната група на програмата htg е 1001. Така че, въпреки че е стартирана от Dave, тя работи с разрешенията на членовете в групата mary. Това е същото, сякаш Дейв се беше присъединил към групата на Мери.
Нека приложим бита SGID към директория. Първо, ще създадем директория, наречена „работа“, и след това ще променим нейната група на „geek“. След това ще зададем бита SGID в директорията.
Когато използваме ls за проверка на настройките на директорията, ще използваме и опцията -d (директория), така че да виждаме подробностите за директорията, а не нейното съдържание.
Въведем следните команди:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
Битът SGID и групата „geek“ са зададени. Те ще засегнат всички елементи, създадени в работната директория.
Въведем следното, за да влезем в работната директория, да създадем директория, наречена „demo“, и да проверим нейните свойства:
cd work
mkdir demo
ls -lh -d demo
Битът SGID и групата „geek“ се прилагат автоматично към директорията „demo“.
Нека напишем следното, за да създадем файл с докосване команда и проверете нейните свойства:
touch useful.sh
ls -lh useful.sh
Групата на новия файл автоматично се настройва на „geek“.
The Sticky Bit
Лепкавата част получава името си от историческото си предназначение. Когато е зададен на изпълним файл, той отбелязва на операционната система, че текстовите части на изпълнимия файл трябва да се държат в swap, което прави повторното им използване по-бързо. В Linux лепкавият бит засяга само директория – поставянето му във файл няма да има смисъл.
Когато зададете лепкав бит в директория, хората могат да изтриват само файлове, които им принадлежат в тази директория. Те не могат да изтриват файлове, които принадлежат на някой друг, без значение коя комбинация от разрешения за файлове са зададени за файловете.
Това ви позволява да създадете директория, която всеки – и процесите, които стартират – могат да използват като споделено съхранение на файлове. Файловете са защитени, защото отново никой не може да изтрие нечии файлове.
Нека създадем директория, наречена „споделена“. Ще използваме символичния режим o+t с chmod, за да зададем лепкавия бит в тази директория. След това ще разгледаме разрешенията за тази директория, както и директориите /tmp и /var/tmp.
Въведем следните команди:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Ако лепкавият бит е зададен, изпълнимият бит от „другия“ набор от разрешения за файлове е зададен на „t“. Името на файла също е маркирано в синьо.
Папките /tmp и /var/tmp са два примера за директории, които имат всички разрешения за файлове, зададени за собственика, групата и други (затова са маркирани в зелено). Те се използват като споделени местоположения за временни файлове.
С тези разрешения всеки трябва теоретично да може да прави всичко. Въпреки това, лепкавият бит ги отменя и никой не може да изтрие файл, който не му принадлежи.
Напомняния
Следва кратък контролен списък на това, което покрихме по-горе за бъдеща справка:
SUID работи само с файлове.
Можете да приложите SGID към директории и файлове.
Можете да приложите само залепващия бит към директории.
Ако индикаторите „s“, „g“ или „t“ се появяват с главни букви, изпълнимият бит (x) не е зададен.