Kada treba izbjegavati sudo u Linuxu i kako ga sigurno koristiti

Početna » piton » Kada treba izbjegavati sudo u Linuxu i kako ga sigurno koristiti

Ako tek sletite svijet Linuxa i pitate se kada biste trebali ili ne biste trebali koristiti sudo, niste ni blizu sami. Mnogi novi korisnici instaliraju distribucije poput Archa, Ubuntua ili Debiana, prate kratki YouTube tutorijal i na kraju gotovo refleksno kucaju sudo, bez da zaista razumiju rizike koji stoje iza toga. Ta navika može funkcionirati neko vrijeme, ali također otvara vrata ozbiljnim sigurnosnim problemima i gadnim greškama.

Cilj ovog vodiča je da objasni na jasan i praktičan način kada sudo ima smisla, kada ga je bolje izbjegavati i kako ojačati njegovu konfiguraciju kako ne bi postao najslabija karika vašeg sistema. Također ćemo uporediti sudo sa su i direktnim root prijavama, proći kroz uobičajene pogrešne konfiguracije i pokazati stvarne primjere kako napadač može pretvoriti naizgled bezopasno sudo pravilo u potpuni root shell.

Šta je sudo zapravo i zašto je toliko važan

sudo („superuser do“) je kontrolni sloj koji omogućava neprivilegovanom korisniku da izvršava određene naredbe kao root ili kao drugi korisnik, pod strogim pravilima i uz evidentiranje. Umjesto da ljudima date root lozinku i kažete im "budite oprezni", delegirate male, dobro definirane ovlasti.

Kada se dobro konfiguriše, sudo vam daje četiri velike prednosti: sljedivost radnji, granularno delegiranje, vremenski ograničeno povećanje privilegija i manja izloženost root računa. Svaka komanda koja prolazi kroz sudo može se evidentirati s pozivajućim korisnikom, datumom i vremenom te tačnom komandnom linijom.

Međutim, loše konfigurisan sudo brzo prelazi iz zaštite u ranjivost. Jedno samo nemarno pravilo (na primjer, opasna naredba dozvoljena bez ograničenja argumenata) može dovesti do trenutne eskalacije privilegija do potpunog root-a. Mnogi visokoprofilni sigurnosni incidenti na Linuxu imali su sudo u središtu, ne zato što je sudo inherentno nesiguran, već zato što su pravila napisana nepažnjom.

Još jedan praktičan problem je taj što većina desktop i mnoge serverske distribucije dolaze s instaliranim sudo-om, koji je često unaprijed omogućen za prvog korisnika kreiranog tokom instalacije. Taj korisnik obično dobija pune root dozvole putem sudo naredbe, ponekad uz period odgode u kojem može nastaviti pokretati sudo naredbe bez ponovnog upisivanja lozinke. Praktično, sigurno; sigurno po defaultu, ne baš.

Zašto je ostavljanje sudo-a "kakvim jeste" sigurnosna greška

Vrlo uobičajen i opasan obrazac je instaliranje distribucije, prihvatanje zadanih sudo postavki i više nikada ne diranje /etc/sudoers ili bilo koje sudo konfiguracije. U mnogim sistemima to znači: vaš svakodnevni korisnik može raditi bilo šta kao root, i nekoliko minuta nakon što jednom unese lozinku, može nastaviti s eskalacijom bez ikakve daljnje autentifikacije.

Taj "grace period" je posebno problematičan. Mnoge distribucije konfigurišu sudo tako da nakon autentifikacije možete pokrenuti dodatne sudo naredbe tokom određenog prozora (često pet minuta) bez ponovnog unosa lozinke. Ako tokom tog prozora neki zlonamjerni proces, skripta ili napadač dobije kontrolu nad vašom sesijom, mogli bi izvršiti sudo bez potrebe za vašom lozinkom.

Nedavne sudo ranjivosti su eksplicitno iskoristile ovakve vrste podrazumijevanih postavki. Čim se sudo instalira, omogući i dozvoli mu se puna root prava glavnom korisniku, svaka greška u samom sudo-u ili srodnim komponentama odmah postaje mnogo lakše iskoristiva.

Neki administratori koji su svjesni sigurnosti zapravo preferiraju distribucije poput klasičnih Debian instalacija koje ne omogućavaju sudo za prvog korisnika po defaultu. Oni kreiraju root lozinku, koriste root eksplicitno za administrativne zadatke i ili onemogućavaju sudo ili ga drže instaliranog, ali zaključanog tako da njihov dnevni račun ne može ništa pokrenuti putem sudo-a.

Bez obzira da li se pridržavate tog strogog pristupa ili ne, ključna lekcija je sljedeća: korištenje sudo naredbe bez pregleda i osiguranja njene konfiguracije predstavlja veliki sigurnosni rizik. Trebali biste barem onemogućiti period odgode, izbjegavati široka NOPASSWD pravila i razumjeti tačno koje naredbe vaši korisnici mogu pokretati kao root.

sudo vs root vs su: šta se zapravo mijenja

Prije nego što odlučite kada treba izbjegavati sudo, morate biti kristalno jasni u vezi s tim kako se sudo razlikuje od su i od direktnog prijavljivanja kao root. Sva tri načina vam u konačnici daju root moći, ali to rade na različite načine i s različitim profilima rizika.

Rad direktno kao root znači da ste prijavljeni kao svemoćni administratorski račun. Nema dodatnog koraka potvrde kada izvršavate destruktivnu komandu kao što je rm -rf /Također nema dijaloškog okvira ili zaštitne ograde: ako napravite grešku u kucanju, sistem će vas odmah poslušati, često s nepovratnim posljedicama.

Klasični Unix pristup je bio da se administratori prijave kao root na terminalu, obave administrativne poslove, zatim se odjave i nastave kao normalni korisnici za e-poštu, uređivanje dokumenata ili pisanje skripti. Vremenom, kako su serveri s više korisnika i udaljeni pristup putem SSH-a postali sveprisutni, ova navika „uvijek preskoči na root“ pokazala se previše rizičnom i preteškom za reviziju.

Naredba su („prebaci korisnika“) je most između računa. Trčanjem su Možete postati drugi korisnik (često root) unutar vaše trenutne sesije. Standardno su traži lozinku ciljnog korisnika, kako bi postao root sa su Morate znati root lozinku. Kada postanete root, ostajete root dok ne pokrenete exit i vratite se na svoj prvobitni račun.

su - (sa crticom) ide korak dalje i učitava puno okruženje za prijavu ciljnog korisnika. Ako ti uradiš su - Za root, dobijate root-ove varijable okruženja, konfiguraciju ljuske, PATH i tako dalje, potpuno isto kao da ste se direktno prijavili kao root na ekranu za prijavu.

sudo mijenja model: umjesto da zahtijeva root lozinku, koristi vašu vlastitu lozinku plus centralno definirana pravila u /etc/sudoers da odluči što smijete učiniti. Ostajete kao vaš normalni korisnik, a sudo vam selektivno dodjeljuje povišena prava samo za naredbu koju izvršavate.

Ključna sigurnosna implikacija je da, sa sudo komandom, nikada ne morate dijeliti root lozinku ni sa kim. Više administratora može dobiti kontrolirani pristup putem sudo naredbe, pri čemu se svaki od njih autentificira vlastitom lozinkom za prijavu. Ako trebate opozvati administratorske ovlasti jednoj osobi, uklonite je iz konfiguracije sudoersa; ne morate rotirati root lozinku i distribuirati je svima ostalima.

Kada je sudo bolji od su i direktnih root prijava

Kada se pravilno koristi, sudo je sigurniji od prijavljivanja kao root ili korištenja običnog su naredbe za gotovo sve svakodnevne administrativne poslove. Ključna riječ je „ispravno“: morate definirati ograničena, revizijska pravila, a ne samo dati opći pristup.

Sa sigurnosne tačke gledišta, su ima dvije velike slabosti u poređenju sa sudo. Prvo, ako nekoliko osoba treba administratorski pristup, svi moraju znati root lozinku, što povećava šanse za curenje podataka, ponovnu upotrebu na drugim sistemima i poteškoće u opozivu pristupa samo jednoj osobi. Drugo, kada korisnik pokrene su i postane root, sve što rade u toj root ljusci teško je pripisati određenom ljudskom korisniku.

S druge strane, sudo po defaultu evidentira svaki pokušani i uspješni privilegirani zadatak. Zapisnici obično pokazuju koji je korisnik pokrenuo koju komandu, s kojeg terminala i u koje vrijeme. Taj nivo sljedivosti je neprocjenjiv i za otklanjanje grešaka i za forenzičku analizu ako nešto pođe po zlu.

Druga razlika je ponašanje tokom vremena. Podrazumevano su Sesija nema vremensko ograničenje; možete zaboraviti da ste root i nastaviti tipkati naredbe satima, možda i danima, u istoj ljusci. Umjesto toga, sudo je obično konfiguriran tako da svaka naredba zahtijeva autentifikaciju i sesija brzo ističe (osim ako ne promijenite zadane postavke ili omogućite period odgode).

U sistemima s više korisnika ili okruženjima sa zahtjevima usklađenosti, princip najmanjih privilegija snažno favorizira sudo. Svakoj ulozi možete dati tačno minimalne naredbe koje su joj potrebne - na primjer, dozvoliti korisniku koji ima pravo na "raspoređivanje" samo da ponovo pokrene određenu uslugu, ali ne i da uređuje proizvoljne datoteke, dodaje korisnike ili montira diskove.

Kada biste trebali izbjegavati sudo i koristiti direktno root

Možda zvuči paradoksalno, ali u nekim situacijama, izbjegavanje sudo-a i direktno korištenje root naloga je zapravo sigurniji izbor, posebno ako niste spremni pravilno zaštititi sudo. Najveći rizik sa sudo-om nije sam alat, već loše konfiguracije i neprovjerene zadane postavke.

Neki administratori preferiraju tijek rada u kojem je sudo onemogućen ili vrlo ograničen, a administrativne zadatke obavljaju prijavom kao root ili korištenjem su - privremeno. U tom modelu, vaš svakodnevni korisnik nema sudo ovlaštenja, a svako kompromitovanje tog korisničkog računa ne znači automatski root pristup putem sudo-a.

Ako ste zabrinuti zbog novootkrivenih ranjivosti sudo komande, ovaj pristup ima dodatnu prednost: ako se sudo uopće ne koristi za eskalaciju privilegija, mnoge od tih grešaka jednostavno se ne odnose na vaš sistem. Napadači koji uspiju probiti sudo ne mogu eskalirati ako ne postoje relevantna sudoers pravila koja daju ovlasti vašim redovnim korisnicima.

Također biste mogli izbjegavati sudo za naredbe koje su inherentno široke, složene ili sklone zloupotrebi. Umjesto da dozvolite korisniku da pokrene visokorizičnu komandu sa sudo komandom, nakratko se prijavite kao root, pokrenete ono što vam je potrebno i odjavite se. Ovo smanjuje broj izloženih površina za napad, ali smanjuje praktičnost.

Uprkos tome, prelazak na "potpuno rootovanje" ima svoje nedostatke: gubite prednosti preciznog delegiranja i revizije koje nudi sudo. Najzdraviji obrazac za mnoge male postavke je da sudo komanda bude dostupna, ali samo za vrlo malu grupu pouzdanih administratora, sa strogim listama dozvoljenih komandi, bez perioda odgode i redovnim pregledima logova.

Očvršćavanje sudoera: principi i dobre prakse

Ako se odlučite koristiti sudo — što je realnost u većini modernih distribucija — trebali biste uložiti vrijeme u jačanje zaštite podataka /etc/sudoers i pratećih datoteka. Loše dizajnirana pravila su daleko opasnija od potpunog nepostojanja sudo-a.

Prvo pravilo je: nikada ne uređujte /etc/sudoers direktno pomoću običnog editora poput vima ili nano-a. Uvek koristite visudoOvaj specijalni omotač zaključava datoteku tako da ne dobijate istovremene izmjene od više administratora i, što je ključno, provjerava sintaksu prije spremanja. Ako napravite grešku, visudo će vas upozoriti i izbjeći primjenu neispravne konfiguracije koja bi mogla blokirati sudo naredbu svima.

Još bolje, nemojte stavljati sve dozvole u jednu monolitnu sudoers datoteku. Moderni sudo ima modularni sistem: glavna datoteka /etc/sudoers može uključivati ​​dodatne datoteke iz /etc/sudoers.d/. Ovo vam omogućava da čuvate odvojene datoteke po ulozi, aplikaciji ili korisniku, kao što su /etc/sudoers.d/deploy, /etc/sudoers.d/monitoring or /etc/sudoers.d/ci.

Taj modularni pristup znatno olakšava reviziju i refaktorisanje. Umjesto pregledavanja ogromne, zamršene konfiguracije, možete na prvi pogled vidjeti šta svaka uloga smije raditi, pratiti promjene u kontroli verzija i vratiti određene skupove pravila ako nešto pođe po zlu.

Unutar sudoer-a, aliasi su vaši prijatelji. Možete definirati aliase za korisnike, hostove, naredbe i ciljeve "pokreni kao". Na primjer:

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

Ovaj obrazac poboljšava jasnoću: ako trebate podesiti koje su komande dozvoljene, alias mijenjate na jednom mjestu umjesto da pretražujete više redova. Također smanjuje greške u konfiguraciji, jer je manja vjerovatnoća da ćete više puta pogrešno upisati dugačke putanje komandi.

Bijele liste naspram crnih lista komandi u sudo komandi

Prilikom odlučivanja koje komande dozvoliti sa sudo komandom, trebali biste razmišljati u smislu strogih bijelih lista, a ne crnih lista. Bijela lista eksplicitno nabraja tačne komande i obrasce argumenata koje smatrate sigurnim. Crna lista pokušava dozvoliti „sve osim nekoliko loših stvari“, što je gotovo uvijek moguće zaobići.

Pravilo sigurnih sudoersa obično uključuje punu apsolutnu putanju do binarne datoteke i, idealno, ograničava prihvatljive argumente. Na primjer, nešto poput:
alice ALL=(root) /usr/bin/systemctl restart nginx
daje Alici mogućnost ponovnog pokretanja Nginx-a, ali ništa više.

Nasuprot tome, modeli stavljanja na crnu listu (na primjer, „dozvoli sve naredbe osim /bin/sh, /bin/bash, /usr/bin/vim“) gotovo uvijek nešto propuste. Previše programa sadrži funkcije za pokretanje ljuske, izvršavanje vanjskih naredbi ili manipuliranje proizvoljnim datotekama. Korisnici će na kraju pronaći put da zaobiđu vašu crnu listu.

U okruženjima osjetljivim na sigurnost, crne liste treba rezervirati za vrlo specifične, pažljivo pregledane slučajeve, a čak ni tada ne bi trebale biti vaša glavna zaštita. Vaš zadani stav uvijek bi trebao biti „uskratite sve; dozvolite samo ono što je neophodno“.

Još jedna nedovoljno korištena opcija ojačavanja je NOEXEC. sudo se može konfigurirati tako da se određene naredbe izvršavaju sa posebnom bibliotekom (često libsudo_noexec.so) unaprijed učitan koji blokira pokušaje izvršavanja podnaredbi. Ovo smanjuje rizik programa koji interno imaju funkciju "exec".

Programi koje gotovo nikada ne biste trebali dozvoliti putem sudo naredbe

Neki programi su toliko moćni ili fleksibilni da je omogućavanje korisnicima koji nisu root korisnici da ih pokreću pod sudo komandom gotovo ekvivalentno davanju root ljuske. Ovi alati se generalno nikada ne bi trebali pojavljivati ​​u pravilima sudoersa, osim u ultra-specijalizovanim, strogo kontrolisanim scenarijima.

Neiscrpna lista uključuje tekstualne urednike i programe za pregled stranica, interpretere i ljuske, alate sa stilskim opcijama -exec, alate za kompresiju i arhiviranje, mrežne uslužne programe sa proizvoljnim komandnim hookovima i sve što može pisati proizvoljne datoteke. Primjeri:

• Urednici i pejdžeri: vim, vi, nano (ako može pozivati ​​komande), less, more.
• Školjke i interpretatori: bash, sh, zsh, ksh, python*, perl, ruby, tclsh.
• Alati sa ponašanjem sličnim exec-u: find, xargs, awk, sed (sa nesigurnim skriptama), tar, rsync, curl or wget kada mogu preuzeti i izvršavati skripte.
• Arhivari: zip, unzip, ar, cpio.
• Programi sa ugrađenim ljuskama ili interaktivnim mehanizmima: tcpdump, openssl u CLI modu, ljuske baze podataka poput mysql or psql.
• Proizvoljni programi za pisanje datoteka: cat, tee, dd.

Ako vam komanda omogućava pokretanje podljuske, pokretanje proizvoljnih sistemskih komandi ili pisanje na proizvoljnu putanju, ona je gotovo uvijek loš kandidat za sudo pristup za obične korisnike. Čak i sa NOEXEC-om, kreativni napadači ponekad mogu ulančati sistemske pozive ili iskoristiti drugo ponašanje sistema kako bi zaobišli ograničenja.

Najsigurnije pravilo: ako niste 100% sigurni da se naredba ne može zloupotrijebiti za dobijanje ljuske ili pisanje proizvoljnih datoteka, nemojte je davati putem sudo naredbe osobama koje nisu administratori. Umjesto toga, dizajnirajte specifične omotačke skripte koje rade samo ono što je potrebno i dozvolite te skripte pod sudo naredbom sa pažljivo kontrolisanim putanjama i dozvolama.

Primjer iz stvarnog svijeta: zašto je "sudo nginx" zamka

Da biste vidjeli koliko opasno može biti naivno sudo pravilo, razmotrite vrlo realističan primjer: omogućavanje korisniku da pokrene nginx kao root putem sudo-a. Primamljivo je napisati liniju u sudoerima poput:
deploy ALL=(root) NOPASSWD: /usr/sbin/nginx

Na prvi pogled, ovo izgleda sigurno. Pravilo koristi apsolutnu putanju, nema zvjezdica ili džoker znakova, a nginx je respektabilan web server. Administrator bi mogao pomisliti da ovo jednostavno omogućava korisniku koji vrši implementaciju da ponovo pokrene ili ponovo pokrene servis.

Problem je što sudo ne ograničava argumente osim ako mu to ne kažete. Ako korisnik implementacije može pokrenuti sudo /usr/sbin/nginx, oni također mogu izvršavati naredbe kao što su sudo /usr/sbin/nginx -c /path/to/custom.conf or sudo /usr/sbin/nginx -g "some directives".nginx zatim izvršava te opcije kao root.

Pomoću posebno kreiranih konfiguracijskih datoteka ili direktiva -g, napadač može zloupotrijebiti nginx za prepisivanje proizvoljnih datoteka, ubacivanje vlastitih SSH ključeva u root-ov authorized_keys ili učitavanje zlonamjernih modula u serverski proces. Budući da se nginx pokreće kao root tokom pokretanja, sve operacije s datotekama navedene tamo su efektivno root operacije.

Na primjer, korištenjem -c ukazati nginxu na lažnu konfiguraciju gdje error_log ili pid pokazuju na osjetljive sistemske putanje koje mogu oštetiti ili prepisati kritične datoteke kao što je /etc/sudoers. Slično tome, a load_module Direktiva koja upućuje na .so datoteku koju kontrolira napadač natjerat će nginx da učita i izvrši proizvoljni kod kao root.

Odatle je jednostavno kreirati datoteke sa SUID bitovima, izbaciti skripte maskirane kao logovi ili na drugi način preći na potpuni root shell. Sve je ovo počelo od naizgled "bezopasne" sudoers linije bez džoker znakova.

Ispravan način za rješavanje ove situacije je da na bijelu listu stavite samo sigurne podkomande koje su vam zaista potrebne. Za nginx administraciju, to bi moglo izgledati ovako:

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

Ovdje eksplicitno dozvoljavate samo testiranje konfiguracije i kontrolirana ponovna učitavanja ili operacije ponovnog otvaranja. Također ih kombinirate s NOEXEC-om kako biste smanjili mogućnost podljuski ili izvršnih poziva unutar nginx biblioteka. Ne postoji način da korisnik proslijedi proizvoljne -c or -g opcije, a naredbe su u potpunosti podložne reviziji i samodokumentiraju se.

Okruženje, urednici i drugi suptilni sudo rizici

Jedna suptilna klasa sudo ranjivosti dolazi od varijabli okruženja i editora, a ne od samih naredbi. Ako dozvolite nepouzdane varijable okruženja poput LD_PRELOAD ili LD_LIBRARY_PATH, korisnik bi mogao prevariti sudo da učita zlonamjerne biblioteke tokom izvršavanja, efektivno dobijajući izvršavanje koda kao root čak i za "sigurne" binarne datoteke.

Da bi se ovo ublažilo, sudo podržava podrazumevane vrednosti koje resetuju ili strogo kontrolišu okruženje. Uobičajeni obrazac za određenog korisnika može biti:
Defaults:alice env_reset, !env_keep+=LD_PRELOAD, !env_keep+=LD_LIBRARY_PATH
što osigurava da ove varijable ne prežive u privilegovane naredbe.

Urednici su još jedan čest izvor problema. Mnogi tekstualni editori, uključujući vim, emacs, a ponekad i nano, mogu pokretati shell-ove ili proizvoljne naredbe. Ako koristite takve potpuno funkcionalne editore za direktno upravljanje sudoer-ima ili drugim konfiguracijskim datotekama u vlasništvu root-a, kompromitovano okruženje ili dodatak mogu se zloupotrijebiti za dobijanje root ovlasti.

Za uređivanje sudoer-a putem visudo-a, sigurnije je koristiti ograničene ili minimalne editore. Primjeri uključuju vi -Z (ograničeni način rada), nano -Rili vrlo male alate poput edMožete konfigurirati visudo da koristi određeni editor putem varijable okruženja EDITOR:

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

Pažljiv odabir editora za privilegovane datoteke značajno smanjuje površinu za napad. U tom kontekstu želite što je moguće manje dodatne funkcionalnosti: bez ugrađenih skriptnih jezika, bez izlaza iz ljuske, bez vanjskih hook-ova.

Praktični savjeti za radni proces: korištenje sudo-a bez pucanja sebi u nogu

Kao novi korisnik Linuxa, vjerovatno ste u iskušenju da gotovo svemu dodate prefiks sudo „za svaki slučaj“. Iako to može ukloniti poruke o greškama, također vas uči da se olako odnosite prema root pravima, što je upravo ono što biste trebali izbjegavati.

Zdravija navika je prvo pokretati naredbe kao vaš uobičajeni korisnik. Ako sistem odgovori „dozvola odbijena“, stanite i zapitajte se: da li ova komanda zaista zahtijeva povišene privilegije ili pokušavam uraditi nešto što bi trebalo biti urađeno u mom vlastitom početnom direktoriju ili putem nekog drugog mehanizma?

Kada vam je potreban sudo, radije pokrenite jednu komandu putem sudo command umjesto da se upusti u punu korijenovu ljusku. Na taj način, svaka privilegovana akcija je eksplicitna i evidentirana kao zaseban unos. Ako napravite grešku, radijus eksplozije je manji.

Ako zaboravite koristiti sudo i dobijete grešku o dozvoli, možete ponovo upotrijebiti prethodnu naredbu sa sudo !! u mnogim školjkama. Ovo ponovo pokreće posljednju komandu s prefiksom sudo i štedi vam vrijeme kucanja bez zadržavanja u dugotrajnoj root ljusci.

Sačuvajte dugovječne korijenove ljuske (na primjer, putem sudo su - or sudo -su) za rijetke periode održavanja gdje zaista morate izvršiti mnogo povezanih operacija. Čak i tada, izađite čim završite. Također možete konfigurirati svoj prompt da vizualno vrišti kada ste root, kako ne biste zaboravili gdje radite.

Bez obzira na to koji način rada odaberete, izbjegavajte slabljenje sudo-a omogućavanjem potpunog root pristupa bez lozinke za vašeg svakodnevnog korisnika. Linija poput user ALL=(ALL) NOPASSWD:ALL u suštini uklanja jedno od glavnih sigurnosnih svojstava sudo-a - prisilnu ponovnu autentifikaciju - i pretvara svako kompromitovanje ljuske u trenutno kompromitovanje root-a.

Razmišljanje o sudo-u kao o preciznom skalpelu, a ne kao o velikom čekiću, pomoći će vam da vaš sistem bude i upotrebljiv i siguran. Kombinujte pažljivu konfiguraciju sa svjesnim navikama i moći ćete iskoristiti prednosti Sudo-a bez nasljeđivanja njegovih potencijalnih nedostataka.

Na kraju krajeva, učenje kada izbjegavati sudo svodi se na razumijevanje da nije svakom zadatku potreban root pristup, da nije svakom korisniku potrebna široka privilegija i da nije svaka zastavica pogodnosti vrijedna dodatnog rizika. Ako odvojite vrijeme da ojačate postavke vašeg sudoers-a, poštujete moć root-a i favorizirate minimalne dozvole, vaši Linux sistemi će biti daleko manje skloni da padne pod utjecajem jedne nepažljive komande ili lako iskoristive pogrešne konfiguracije.