Кога да избягвате sudo в Linux и как да го използвате безопасно

Начало » Python » Кога да избягвате sudo в Linux и как да го използвате безопасно

Ако току-що сте навлезли в света на Linux и се чудите кога трябва или не трябва да използвате sudo, далеч не сте сами. Много нови потребители инсталират дистрибуция като Arch, Ubuntu или Debian, следват кратък урок в YouTube и в крайна сметка пишат sudo почти рефлекторно, без наистина да разбират рисковете зад него. Този навик може да работи известно време, но също така отваря вратата към сериозни проблеми със сигурността и неприятни грешки.

Целта на това ръководство е да обясни на ясен и практичен език кога sudo има смисъл, кога е по-добре да се избягва и как да се осигури по-добра конфигурация, така че да не се превърне в най-слабото звено на вашата система. Ще сравним sudo със su и директното влизане с root потребители, ще разгледаме често срещани неправилни конфигурации и ще покажем реални примери за това как едно привидно безобидно правило за sudo може да бъде превърнато в пълноценна root обвивка от нападател.

Какво всъщност е sudo и защо е толкова важно

sudo („superuser do“) е контролен слой, който позволява на непривилегирован потребител да изпълнява определени команди като root или като друг потребител, при строги правила и с регистриране. Вместо да давате на хората root паролата и да им казвате „бъдете внимателни“, вие делегирате малки, добре дефинирани правомощия.

Когато е добре конфигуриран, sudo ви дава четири големи предимства: проследимост на действията, гранулирано делегиране, ограничено във времето повишаване на правата и по-малко излагане на root акаунта. Всяка команда, която преминава през sudo, може да бъде регистрирана с извикващия потребител, дата и час и точния команден ред.

Въпреки това, лошо конфигурираният sudo бързо се превръща от защита в уязвимост. Едно-единствено небрежно правило (например опасна команда, разрешена без ограничения за аргументи) може да доведе до незабавно ескалиране на привилегиите до пълен root. Много нашумели инциденти със сигурността на Linux са имали sudo в центъра, не защото sudo е по своята същност несигурен, а защото правилата са били написани небрежно.

Друг практически проблем е, че повечето настолни и много сървърни дистрибуции се доставят с инсталиран sudo, който често е предварително активиран за първия потребител, създаден по време на инсталацията. Този потребител обикновено получава пълни root права чрез sudo, понякога с гратисен период, в който може да продължи да изпълнява sudo команди, без да въвежда отново паролата си. Удобно, разбира се; безопасно по подразбиране, не чак толкова.

Защо оставянето на sudo „такъв, какъвто е“ е грешка в сигурността

Много често срещан и опасен модел е да се инсталира дистрибуция, да се приеме настройката по подразбиране на sudo и никога повече да се не докосва /etc/sudoers или каквато и да е sudo конфигурация. В много системи това означава: вашият обикновен потребител може да прави всичко като root и в продължение на няколко минути след въвеждане на паролата веднъж, той може да продължи да ескалира без никакво допълнително удостоверяване.

Този „гратисен период“ е особено проблематичен. Много дистрибуции конфигурират sudo така, че след като се удостоверите, можете да изпълнявате допълнителни sudo команди за конфигурируем прозорец (често пет минути), без да въвеждате отново паролата си. Ако през този прозорец някой злонамерен процес, скрипт или атакуващ получи контрол над вашата сесия, той може да изпълни sudo, без изобщо да се нуждае от вашата парола.

Последните уязвимости в sudo изрично се възползват от тези настройки по подразбиране. В момента, в който sudo е винаги инсталиран, широко активиран и му е позволено да дава пълни root права на основния потребител, всяка грешка в самия sudo или в свързаните с него компоненти веднага става много по-уязвима.

Някои администратори, загрижени за сигурността, всъщност предпочитат дистрибуции като класическите инсталации на Debian, които не активират sudo за първия потребител по подразбиране. Те създават root парола, използват root изрично за административни задачи и или деактивират sudo, или го оставят инсталиран, но заключен, така че ежедневният им акаунт да не може да изпълнява нищо чрез sudo.

Независимо дали следвате този стриктен подход или не, ключовият урок е следният: използването на sudo без преглед и засилване на неговата конфигурация е сериозен риск за сигурността. Трябва поне да деактивирате гратисния период, да избягвате общите правила NOPASSWD и да разбирате точно кои команди вашите потребители могат да изпълняват като root.

sudo срещу root срещу su: какво всъщност се променя

Преди да решите кога да избягвате sudo, трябва да сте кристално наясно как sudo се различава от su и от директното влизане като root. И трите начина в крайна сметка ви дават root права, но го правят по различни начини и с различни рискови профили.

Работата директно като root означава, че сте влезли като всемогъщ администраторски акаунт. Няма допълнителна стъпка за потвърждение, когато изпълнявате деструктивна команда, като например rm -rf /Няма и диалогов прозорец или предпазен парапет: ако направите печатна грешка, системата ще ви се подчини незабавно, често с необратими последици.

Класическият подход на Unix беше администраторите да влизат като root в терминал, да извършват административна работа, след което да излизат и да продължават като нормален потребител за имейл, редактиране на документи или писане на скриптове. С течение на времето, тъй като многопотребителските сървъри и отдалеченият достъп чрез SSH станаха повсеместни, този навик „винаги да преминавате към root“ се оказа твърде рискован и твърде труден за одит.

Командата su („превключване на потребител“) е мост между акаунти. Чрез бягане su Можете да станете друг потребител (често root) в рамките на текущата си сесия. Стандартно su иска паролата на целевия потребител, така че да стане root с su Трябва да знаете root паролата. След като сте root, оставате root, докато не стартирате exit и се върнете към първоначалния си акаунт.

su - (с тире) отива още една стъпка и зарежда пълната среда за вход на целевия потребител. Ако го направите su - За да получите root потребител, получавате променливите на средата на root потребител, конфигурацията на обвивката, PATH и т.н., точно както ако сте влезли директно като root потребител на екрана за вход.

sudo обръща модела: вместо да изисква root парола, той използва вашата собствена парола плюс централно дефинирани правила в /etc/sudoers, за да реши какво можете да правите. Вие оставате като нормален потребител и sudo избирателно ви предоставя повишени права само за командата, която изпълнявате.

Ключово значение за сигурността е, че със sudo никога не е нужно да споделяте root паролата с никого. Няколко администратори могат да получат контролиран достъп чрез sudo, като всеки от тях е удостоверен със собствена парола за вход. Ако е необходимо да отнемете администраторските правомощия на едно лице, го премахвате от конфигурацията на sudoers; не е необходимо да ротирате root паролата и да я разпространявате на всички останали.

Кога sudo е за предпочитане пред su и директно влизане с root права

Когато се използва правилно, sudo е по-безопасно от влизането като root или използването на обикновен su за почти цялата ежедневна административна работа. Ключовата дума е „правилно“: трябва да дефинирате ограничени, одитираеми правила, а не просто да давате общ достъп.

От гледна точка на сигурността, su има две големи слабости в сравнение със sudo. Първо, ако няколко души се нуждаят от администраторски достъп, всички те трябва да знаят root паролата, което увеличава шансовете за изтичане на данни, повторна употреба на други системи и трудност при отнемане на достъп само за един човек. Второ, след като потребителят стартира su и става root, всичко, което правят в тази root обвивка, е трудно да се припише на конкретен човешки потребител.

За разлика от това, sudo регистрира по подразбиране всеки опит за успешно изпълнение на привилегирована команда. Регистрите обикновено показват кой потребител е изпълнил коя команда, от кой терминал и по кое време. Това ниво на проследяване е безценно както за отстраняване на грешки, така и за криминалистичен анализ, ако нещо се обърка.

Друга разлика е поведението във времето. По подразбиране su Сесията няма ограничение във времето; можете да забравите, че сте root и да продължите да пишете команди с часове, може би дни, в една и съща обвивка. Вместо това sudo обикновено е конфигуриран така, че всяка команда изисква удостоверяване и сесията изтича бързо (освен ако не промените настройките по подразбиране или не активирате гратисен период).

В многопотребителски системи или среди с изисквания за съответствие, принципът на най-малките привилегии силно благоприятства sudo. Можете да дадете на всяка роля точно минималните команди, от които се нуждае – например, да позволите на потребител с „разполагане“ само да рестартира определена услуга, но не и да редактира произволни файлове, да добавя потребители или да монтира дискове.

Кога трябва да избягвате sudo и да използвате root директно

Може да звучи парадоксално, но в някои ситуации избягването на sudo и директното използване на root акаунта всъщност е по-безопасният избор, особено ако не сте склонни да защитите sudo правилно. Най-големият риск със sudo не е самият инструмент, а небрежните конфигурации и непроверените настройки по подразбиране.

Някои администратори предпочитат работен процес, при който sudo е деактивиран или много ограничен, и изпълняват административни задачи, като влизат като root или използват su - временно. В този модел вашият ежедневен потребител няма правомощия за sudo и всяко компрометиране на този потребителски акаунт не се превръща автоматично в root достъп чрез sudo.

Ако се притеснявате за новооткрити уязвимости в sudo, този подход има допълнително предимство: ако sudo изобщо не се използва за ескалация на привилегиите, много от тези грешки просто не се отнасят за вашата система. Атакуващите, които успеят да пробият sudo, не могат да ескалират, ако няма съответни правила в sudoers, предоставящи правомощия на вашите редовни потребители.

Можете също така да избягвате sudo за команди, които са по своята същност обширни, сложни или склонни към злоупотреба. Вместо да позволите на потребител да изпълни високорискова команда със sudo, вие влизате за кратко като root, изпълнявате това, което ви е необходимо, и излизате. Това намалява броя на откритите повърхности за атака, но за сметка на по-малко удобство.

Въпреки това, преминаването към „изцяло root“ има свои собствени компромиси: губите предимствата на sudo за фино делегиране и одит. Най-здравословният модел за много малки системи е sudo да се поддържа достъпен, но само за много малка група доверени администратори, със строги бели списъци с команди, без гратисен период и редовни прегледи на лог файловете.

Втвърдяване на судоери: принципи и добри практики

Ако решите да използвате sudo — което е реалността в повечето съвременни дистрибуции — трябва да инвестирате време в подобряване на /etc/sudoers и съпътстващите го файлове. Лошо проектираните правила са много по-опасни от това изобщо да нямате sudo.

Първото правило е: никога не редактирайте /etc/sudoers директно с обикновен редактор като vim или nano. Винаги използвайте visudoТази специална обвивка заключва файла, така че да не получавате едновременни редакции от множество администратори и, което е изключително важно, валидира синтаксиса преди запазване. Ако допуснете грешка, visudo ще ви предупреди и ще избегне прилагането на повредена конфигурация, която може да блокира всички от sudo.

Още по-добре е да не натъпквате всички разрешения в един единствен монолитен sudoers файл. Съвременният sudo има модулна система: основният файл /etc/sudoers може да включва допълнителни файлове от /etc/sudoers.d/. Това ви позволява да съхранявате отделни файлове за всяка роля, приложение или потребител, като например /etc/sudoers.d/deploy, /etc/sudoers.d/monitoring or /etc/sudoers.d/ci.

Този модулен подход прави одита и рефакторинга много по-лесни. Вместо да преглеждате огромна, заплетена конфигурация, можете да видите с един поглед какво е позволено да прави всяка роля, да проследявате промените в контрола на версиите и да отменяте конкретни набори от правила, ако нещо се обърка.

В sudoers, псевдонимите са ваши приятели. Можете да дефинирате псевдоними за потребители, хостове, команди и цели „изпълнява се като“. Например:

Cmnd_Alias DEPLOY_CMDS = /usr/bin/systemctl restart tomcat, /usr/bin/git pull
User_Alias DEPLOYERS = deploy, jenkins
DEPLOYERS ALL=(root) DEPLOY_CMDS

Този модел подобрява яснотата: ако трябва да промените кои команди са разрешени, променяте псевдонима на едно място, вместо да преглеждате множество редове. Това също така намалява грешките в конфигурацията, тъй като е по-малко вероятно да въведете многократно грешни пътища при дълги команди.

Бели списъци с команди срещу черни списъци в sudo

Когато решавате кои команди да разрешите със sudo, трябва да мислите от гледна точка на строги бели списъци, а не на черни списъци. Белият списък изброява изрично точните команди и модели на аргументи, които считате за безопасни. Черният списък се опитва да разреши „всичко с изключение на няколко лоши неща“, което почти винаги е заобиколно.

Правилото за безопасни sudoers обикновено включва пълния абсолютен път до двоичен файл и в идеалния случай ограничава приемливите аргументи. Например, нещо като:
alice ALL=(root) /usr/bin/systemctl restart nginx
дава на alice възможността да рестартира nginx, но нищо повече.

За разлика от това, моделите за черни списъци (например „позволяват всички команди с изключение на /bin/sh, /bin/bash, /usr/bin/vim“) почти неизменно пропускат нещо. Твърде много програми съдържат функции за създаване на обвивка (shell), изпълнение на външни команди или манипулиране на произволни файлове. Потребителите в крайна сметка ще намерят път, заобиколен от вашия черен списък.

В среди, чувствителни към сигурността, черните списъци трябва да бъдат запазени за много специфични, внимателно прегледани случаи и дори тогава те не трябва да бъдат вашата основна защита. Вашата позиция по подразбиране винаги трябва да бъде „отказвайте всичко; разрешавайте само точно това, което е необходимо“.

Друга недостатъчно използвана опция за втвърдяване е NOEXEC. sudo може да бъде конфигуриран така, че определени команди да се изпълняват със специална библиотека (често libsudo_noexec.so), който блокира опитите за изпълнение на подкоманди. Това намалява риска от програми, които имат вътрешна функция „exec“.

Програми, които почти никога не бива да разрешавате чрез sudo

Някои програми са толкова мощни или толкова гъвкави, че позволяването на потребители без root права да ги изпълняват под sudo е почти еквивалентно на предоставянето на root shell. Тези инструменти по принцип никога не трябва да се появяват в правилата на sudoers, освен в ултраспециализирани, строго контролирани сценарии.

Неизчерпателен списък включва текстови редактори и пейджъри, интерпретатори и шелове, инструменти с опции в стил -exec, инструменти за компресиране и архивиране, мрежови инструменти с произволни команди и всичко, което може да записва произволни файлове. Примери:

• Редактори и пейджъри: vim, vi, nano (ако може да извиква команди), less, more.
• Обвивки и интерпретатори: bash, sh, zsh, ksh, python*, perl, ruby, tclsh.
• Инструменти с exec-подобно поведение: find, xargs, awk, sed (с опасни скриптове), tar, rsync, curl or wget когато могат да изтеглят и изпълняват скриптове.
• Архиватори: zip, unzip, ar, cpio.
• Програми с вградени обвивки или интерактивни двигатели: tcpdump, openssl в CLI режим, обвивки на бази данни като mysql or psql.
• Произволни автори на файлове: cat, tee, dd.

Ако дадена команда ви позволява да създадете под-обвивка, да изпълнявате произволни системни команди или да записвате в произволен път, тя почти винаги е лош кандидат за sudo достъп за обикновени потребители. Дори с NOEXEC, креативните нападатели понякога могат да верижно обвържат системните извиквания или да използват друго системно поведение, за да заобиколят ограниченията.

Най-безопасното правило: ако не сте 100% сигурни, че дадена команда не може да бъде злоупотребена за получаване на shell или запис на произволни файлове, не я предоставяйте чрез sudo на лица, които не са администратори. Вместо това, създайте специфични обвиващи скриптове, които правят само необходимото, и позволете тези скриптове под sudo с внимателно контролирани пътища и разрешения.

Пример от реалния свят: защо „sudo nginx“ е капан

За да видите колко опасно може да бъде едно наивно sudo правило, разгледайте един много реалистичен пример: позволяване на потребител да стартира nginx като root чрез sudo. Изкушаващо е да напишете ред в sudoers като:
deploy ALL=(root) NOPASSWD: /usr/sbin/nginx

На пръв поглед това изглежда безопасно. Правилото използва абсолютен път, няма звездички или заместващи символи, а nginx е реномиран уеб сървър. Администраторът може да си помисли, че това просто позволява на потребителя да рестартира или презареди услугата.

Проблемът е, че sudo не ограничава аргументите, освен ако не му кажете да го направи. Ако потребителят за внедряване може да изпълни sudo /usr/sbin/nginx, те могат също да изпълняват команди като sudo /usr/sbin/nginx -c /path/to/custom.conf or sudo /usr/sbin/nginx -g "some directives"След това nginx изпълнява тези опции като root.

С помощта на специално създадени конфигурационни файлове или директиви -g, атакуващият може да злоупотреби с nginx, за да презапише произволни файлове, да постави свои собствени SSH ключове в authorized_keys на root или да зареди злонамерени модули в сървърния процес. Тъй като nginx работи от root потребител по време на стартиране, всички файлови операции, посочени там, са ефективно root операции.

Например, използвайки -c да насочва nginx към фалшива конфигурация, където error_log или pid сочат към чувствителни системни пътища, което може да повреди или презапише критични файлове, като например /etc/sudoers. По същия начин, a load_module Директива, сочеща към контролиран от атакуващия .so файл, ще накара nginx да зареди и изпълни произволен код от root потребителското име.

Оттам е лесно да се създават файлове със SUID битове, да се премахват скриптове, маскирани като лог файлове, или по друг начин да се премине към пълна root обвивка. Всичко това започна от привидно „безобиден“ ред sudoers без заместващи символи.

Правилният начин да се справите с тази ситуация е да добавите в белия списък само безопасните подкоманди, от които наистина се нуждаете. За администриране на nginx това може да изглежда така:

Cmnd_Alias NGINX_SAFE = /usr/sbin/nginx -t, /usr/sbin/nginx -s reload, /usr/sbin/nginx -s reopen
deploy ALL=(root) NOPASSWD: NGINX_SAFE
deploy ALL=(root) NOEXEC: NGINX_SAFE

Тук изрично разрешавате само тестване на конфигурацията и контролирани презареждания или операции за повторно отваряне. Можете също така да ги комбинирате с NOEXEC, за да намалите вероятността от под-обвивки или exec извиквания в библиотеките на nginx. Няма начин потребителят да предаде произволни команди. -c or -g опции, а командите са напълно одитираеми и самодокументиращи се.

Среда, редактори и други фини sudo рискове

Един фин клас уязвимости на sudo идва от променливите на средата и редакторите, а не от самите команди. Ако разрешите ненадеждни променливи на средата като LD_PRELOAD или LD_LIBRARY_PATH, потребителят може да подмами sudo да зареди злонамерени библиотеки по време на изпълнение, като по този начин ефективно получи изпълнение на код като root дори за „безопасни“ двоични файлове.

За да се смекчи това, sudo поддържа настройки по подразбиране, които нулират или строго контролират средата. Често срещан модел за конкретен потребител може да бъде:
Defaults:alice env_reset, !env_keep+=LD_PRELOAD, !env_keep+=LD_LIBRARY_PATH
което гарантира, че тези променливи не се запазват в привилегировани команди.

Редакторите са друг чест източник на проблеми. Много текстови редактори, включително vim, emacs и понякога nano, могат да създават обвивки (shells) или да изпълняват произволни команди. Ако използвате такива пълнофункционални редактори за директно управление на sudo-и или други конфигурационни файлове, собственост на root, компрометирана среда или плъгин могат да бъдат злоупотребени за получаване на root права.

За редактиране на sudo-и чрез visudo е по-безопасно да се използват ограничени или минимални редактори. Примери за това са vi -Z (ограничен режим), nano -Rили много малки инструменти като edМожете да конфигурирате visudo да използва специфичен редактор чрез променливата на средата EDITOR:

export EDITOR="/usr/bin/vi -Z"
visudo

Внимателният избор на редактор за привилегировани файлове значително намалява повърхността за атака. В този контекст е необходимо възможно най-малко допълнително количество функционалност: без вградени скриптови езици, без екрани на обвивката, без външни куки.

Практични съвети за работен процес: използване на sudo без да се самозалъгвате

Като нов потребител на Linux, вероятно се изкушавате да добавяте пред почти всичко sudo „за всеки случай“. Макар че това може да премахне съобщенията за грешки, то също така ви учи да се отнасяте небрежно към root правата, което е точно това, което трябва да избягвате.

По-здравословен навик е първо да изпълнявате команди като нормален потребител. Ако системата отговори „permission denied“ (отказан достъп), спрете и се запитайте: наистина ли тази команда изисква повишени привилегии или се опитвам да направя нещо, което трябва да се направи в моята собствена домашна директория или чрез друг механизъм?

Когато имате нужда от sudo, предпочитайте да изпълните една команда чрез sudo command вместо да се спусне в пълна коренова обвивка. По този начин всяко привилегировано действие е изрично и се регистрира като отделен запис. Ако допуснете грешка, радиусът на взрива е по-малък.

Ако забравите да използвате sudo и получите грешка за разрешение, можете да използвате повторно предишната команда с sudo !! в много черупки. Това изпълнява отново последната команда с префикс sudo и ви спестява писане, без да ви държи в дълготрайна root обвивка.

Запазете дълготрайните коренови черупки (например чрез sudo su - or sudo -su) за редки прозорци за поддръжка, където наистина трябва да извършите много свързани операции. Дори тогава, излезте веднага щом приключите. Можете също така да конфигурирате подканата си да ви визуално крещи, когато сте root, за да не забравите къде работите.

Какъвто и работен процес да изберете, избягвайте отслабването на sudo, като активирате пълен root достъп без парола за вашия ежедневен потребител. Линия като user ALL=(ALL) NOPASSWD:ALL по същество премахва едно от основните свойства за сигурност на sudo — принудително повторно удостоверяване — и превръща всяко компрометиране на shell в незабавно компрометиране на root достъпа.

Мисленето за sudo като за прецизен скалпел, а не като за голям чук, ще ви помогне да поддържате системата си едновременно използваема и сигурна. Комбинирайте внимателна конфигурация със съзнателни навици и ще можете да използвате силните страни на sudo, без да наследявате потенциалните му недостатъци.

В крайна сметка, научаването кога да избягвате sudo е свързано с разбирането, че не всяка задача се нуждае от root, не всеки потребител се нуждае от широки привилегии и не всеки флаг за удобство си струва допълнителния риск. Ако отделите време, за да подсилите настройката на sudoers, да уважавате силата на root и да предпочитате минимални разрешения, вашите Linux системи ще бъдат много по-малко склонни да се поддадат на една небрежна команда или лесно използваема неправилна конфигурация.