Kad Linux sistēmā nevajadzētu lietot sudo un kā to pareizi pārvaldīt

PCHardwarePro » Windows » Kad Linux sistēmā nevajadzētu lietot sudo un kā to pareizi pārvaldīt

Ja jūs jau kādu laiku lietojat GNU/Linux, jūs droši vien esat dzirdējuši tūkstoš reižu, ka Pastāvīgas root piekļuves iegūšana ir bīstamaTas attiecas gan uz lokālo serveri, gan mākoņvidi, piemēram, AWS. Diezgan bieži var dzirdēt arī tādus ieteikumus kā "vienmēr izmantojiet sudo" vai "nekad nestrādājiet kā root", taču tas reti tiek detalizēti izskaidrots, kad tas ir piemēroti. izmantojiet sudokad jums ir vislabākais laiks, un, pats galvenais, Kādās situācijās ir svarīgi pēc iespējas izvairīties no svīšanas vai to ierobežot? lai patiesi ievērotu mazāko privilēģiju principu.

Turklāt pastāv ērtības faktors: `sudo` rakstīšana pirms katras komandas un paroles atkārtota ievadīšana kļūst par apgrūtinājumu. Tas dažiem lietotājiem noved pie bīstamām idejām, piemēram, "es vienkārši pārtraukšu pusi sistēmas, un tādā veidā man nebūs nepieciešams `sudo`" vai... Konfigurējiet sudo tā, lai tas neprasītu paroli Nekad. Tie ir vilinoši īsceļi, taču tie var padarīt jūsu datoru neaizsargātu. Turpmākajās rindās mēs to aplūkosim diezgan detalizēti. Kā darbojas sudo, kā tas atšķiras no su un no tiešās root pieteikšanāsKādi konkrētie riski ir saistīti ar katru pieeju un kā to var saprātīgi konfigurēt, lai pastāvīgi neizmantotu sakņu ieroci?

Saknes lietotāji, parastie lietotāji un mazāko privilēģiju princips

Jebkurā Unix līdzīgā sistēmā root konts ir sistēmas galvenā atslēgaVarat izdzēst jebkuru failu, mainīt atļaujas visam, pievienot un atvienot failu sistēmas, modificēt lietotāju kontus, instalēt vai atinstalēt pakotnes, pielāgot darblīmeni... būtībā, ja pieļaujat kļūdu kā root lietotājs, nav apstiprinājuma loga, kas jūs saglabātu.

Vēsturiski agrīnajās Unix sistēmās administrators bija Es pieslēdzos tieši kā root. Viņš izmantoja fizisku termināli vai teletaipu un visu administrēšanu veica ar šo kontu. Dažreiz viņam bija vēl viens "parasts" konts lietotāja uzdevumiem (e-pasts, dokumenti utt.), bet nopietno darbu vienmēr veica kā superlietotājs, bez jebkādiem puspasākumiem vai laika ierobežojumiem.

Līdz ar GNU/Linux popularizēšanos personālajos datoros, ar internetu savienotos serveros un daudzlietotāju vidēs, slavenais mazāko privilēģiju principsKatram kontam jābūt tikai tām atļaujām, kas absolūti nepieciešamas tā darba veikšanai. Ja kādam ir tikai jāaugšupielādē attēli mapē, izmantojot SFTP, nav iemesla, lai viņš varētu izveidot savienojumu kā root lietotājs un modificēt /etc vai /usr/local.

Praktiski tas nozīmē, ka ir saprātīgi izmantot "ierobežotu" lietotāja kontu. 99% ikdienas uzdevumu un paaugstināt privilēģijas tikai tad, ja nepieciešami sistēmas uzdevumi: pakotņu instalēšana, pakalpojumu restartēšana, failu rediģēšana sadaļā /etc, lietotāju pārvaldība utt. Šeit noder sudo un su — divi rīki, kas bieži tiek jaukti, bet tika izstrādāti ar ļoti atšķirīgi mērķi.

No šī viedokļa jautājums vairs nav tikai par to, vai root ir "slikts", bet gan par to, vai jūsu sudo vai su lietošanas veids patiešām ievēro minimālās privilēģijas vai, gluži pretēji, esat izveidojis slepenu pseidosakni, kas padara sistēmu neaizsargātu pret jebkādām drošības kļūmēm vai cilvēku uzraudzību.

Sudo un viņa: ko katrs dara un kāpēc viņi nav vienādi

Lai būtu skaidrs, kad ir svarīgi izvairīties no svīšanas vai to ierobežot, vispirms ir labi jānošķir. Ko dara sviedri un ko dara viņaDaudzās rokasgrāmatās tie tiek lietoti gandrīz kā sinonīmi, taču drošības un audita līmenī tie darbojas ļoti atšķirīgi.

Sudo ir atvasināts no “superuser do”. Tā mērķis ir ļaut lietotājam izpildīt īpaša programma ar cita lietotāja privilēģijām (parasti root), pilnībā nemainot identitāti. Sudo jauda nav tikai pašā paaugstināšanā, bet gan tajā, ka šo deleģēšanu var veikt. precīzi noregulēt līdz milimetram no konfigurācijas faila /etc/sudoers.

Sudo galvenās iezīmes ietver to, ka tā pieprasa lietotāja paša parole (nevis root konts) un reģistrē visu izpildīto sistēmas žurnālos, tādos failos kā /var/log/auth.log vai līdzvērtīgos failos atkarībā no izplatīšanas. Tas ļauj zināt, kas izpildīja kuru komandu, kurā laikā un no kura termināļa — tas ir ļoti svarīgi, ja ir vairāki administratori vai ja nepieciešama izsekojamība.

Turklāt sudo ļauj ļoti detalizēti definēt politikas: kuri lietotāji vai grupas to var izmantot, no kurām iekārtām, ar kādām precīzām komandām, vai ir jāievada parole vai nē, cik ilgi autentifikācija ir derīga (parametrs timestamp_timeout), kurš PATH tiek lietots sudo sesijās, vai visa komandu izvade tiek reģistrēta utt. Pareizi lietojot, sudo ir privilēģiju kontroles Šveices armijas nazis.

Tikmēr "Su" ir atvasināts no "switch user" (pārslēgt lietotāju). Tā galvenais mērķis ir mainīt lietotāja identitāti Sesijas laikā: to var izmantot, lai pārslēgtos uz root lietotāju, kā arī lai pieņemtu jebkuru citu sistēmas kontu. Parasti tas pieprasīs mērķa lietotāja paroli; tas ir, lai vienkārši palaistu `sudo` un kļūtu par root lietotāju, jums jāzina root parole.

Kad pārslēgšanai uz root kontu izmantojat `su`, iegūtais čaulas saturs jau ir pilna root sesijaJūs varat izpildīt tik daudz komandu, cik vēlaties, ar pilnām privilēģijām, līdz aizverat sesiju ar komandu `exit`. Eskalācijai nav laika ierobežojuma vai derīguma termiņa, ja vien jūs pats nebeidzat sesiju. Turpmāk žurnālos vienkārši tiks parādīts, ka "root" ir izdarījis to un to, tieši nesaistot to ar personu, kas to izdarīja, ja parole tika koplietota.

Pastāv svarīgas nianses: `su -` ielādē saknes vidi tā, it kā būtu pieteicies no jauna (ieskaitot PATH un pielāgotos vides mainīgos), savukārt `su` bez defises parasti manto daļu no sākotnējā lietotāja vides. Pastāv arī `su -c "komanda"`, kas izpilda noteiktu komandu kā cits lietotājs un pēc tam atgriežas sākuma kontā, kas ir noderīgi vienreizējiem uzdevumiem, neatverot pilnu interaktīvu čaulu.

Bīstamais hibrīds: sudo su un “maskētas” sakņu čaumalas

Daudzās mūsdienu distribūcijās root konts ir pieejams. atspējots vai bez paroles Pēc noklusējuma. Tas ir tipiski Ubuntu: instalēšanas laikā netiek prasīta root parole un tiek ieteikts visu darīt ar `sudo`. Pat ja tā, parasti root čaulu var atvērt, ierakstot `sudo su` vai `sudo su -` (vai ekvivalentus, piemēram, `sudo -so` vai `sudo -i`, atkarībā no konfigurācijas).

Tur notiek tas, ka sudo izpilda su kā root, izmantojot jūsu paša lietotāja paroleTas notiek pat bez atsevišķas root paroles (vai jums to nezinot). Žurnālos būs redzams, ka jūs palaidāt komandu `sudo`, bet no brīža, kad čaula kļūst par root, jūs sākat strādāt kā pilna laika superlietotājs.

Šis "sudo su" modelis tiek plaši izmantots ērtības labad, jo tas ļauj izvairīties no nepieciešamības rakstīt sudo pirms katras komandas, bet zaudē lielāko daļu svīšanas priekšrocībuJūs pārejat no pagaidu un ierobežotu privilēģiju modeļa uz pilnu root sesiju, kas var ilgt stundām ilgi, ar lielāku iespēju nopietnām kļūdām un mazāku kontroli pār to, kas tieši tika darīts ar paaugstinātām privilēģijām.

Sistēmās, kurās vienu un to pašu datoru pārvalda vairāki cilvēki, šis hibrīds var radīt īpašas problēmas: teorētiski ir iespējams izsekot, kurš ir izmantojis sudo, taču, nokļūstot root čaulā, šo darbību aizsedz šī viena identitāte. Turklāt, ja šī sesija tiek atstāta atvērta nebloķētā terminālī, ikviens, kas atrodas tajā pašā telpā, var viegli piekļūt root piekļuvei.

Tas nenozīmē, ka "svīst" ir aizliegts, bet gan to, ka Tas būtu jārezervē ļoti specifiskiem gadījumiem., piemēram, ilgstoši apkopes uzdevumi, kuros tiešām atmaksājas strādāt kā tīram root lietotājam, un nekad neatstāt šīs sesijas atvērtas bezrūpīgi vai izmantot tās kā savu parasto darba vidi.

Priekšrocības un trūkumi, strādājot tieši kā root

Ir administratori, kuri joprojām dod priekšroku "labajai vecajai saknei" un praktiski Viņi vispār neizmanto sudoĪpaši uz iekārtām, kuras viņi kontrolē vieni paši. Citi kļūst nervozi, tikai dzirdot par tiešu root pieteikšanos, izmantojot SSH. Patiesībā abas pozīcijas atbalsta saprātīgi argumenti.

Darbojoties kā root, ir liela priekšrocība: absolūta darbības vienkāršībaJūs izveidojat savienojumu ar root@server, izmantojot SSH (ja atļauts), vai arī lokālajā konsolē palaižat komandu `su`; turpmāk nav nepieciešams pirms katras komandas rakstīt `sudo` vai mocīties ar sudoer noteikumiem. Tas var būt ļoti ērti liela mēroga uzdevumiem, apkopes skriptiem, sistēmas atjaunošanai vai sākotnējām konfigurācijām.

Problēma ir tā, ka šī ērtība arī atvieglo katastrofu rašanos. Vienkārša neuzmanība ar slikti uzrakstītu `rm -rf`, rekursīvu `chown` nepareizā direktorijā vai slikti pārbaudītu skriptu var radīt nopietnu problēmu. gāzt visu sistēmu bez jebkādiem starpposma šķēršļiem. Un atšķirībā no citām "lietotājam draudzīgākām" operētājsistēmām, Linux jūs neredzēsiet apstiprinājuma lodziņus, kas jautā, vai esat pārliecināts.

Drošības ziņā galvenais root trūkums ir tāds, ka, ja tā parole tiek nopludināta vai kādam izdodas to uzzināt, uzbrucējam būs piekļuve sistēmai. Iegūstiet tūlītēju pilnīgu kontroli Nav nepieciešamas nekādas papildu darbības. Ja turklāt vairākiem cilvēkiem ir viena un tā pati root parole (diemžēl ļoti bieži), piekļuves atsaukšana tikai vienai personai nozīmē tās nomaiņu visiem un pārdalīšanu, ar visām ar to saistītajām organizatoriskajām grūtībām.

Situāciju vēl vairāk pasliktina tas, ka pastāvīga darbība kā root lietotājam nopietni pasliktina izsekojamību: žurnālos būs redzams, ka root lietotājs kaut ko ir darījis, bet ne tas, kas tajā brīdī atradās pie tastatūras. Tā ir liela problēma auditiem, forenzikai un atbilstības nodrošināšanā normatīvajiem aktiem, un arvien vairāk uzņēmumu uzskata to par nepieņemamu.

Visu šo iemeslu dēļ daudzi izplatījumi ir izvēlējušies Atspējot tiešu root pieteikšanos, izmantojot SSH (kā to dara Debian ar opciju PermitRootLogin no) vai pat neļaujot iestatīt root paroli instalēšanas laikā (tāpat kā Ubuntu) un piespiežot izmantot sudo administratīviem uzdevumiem.

Sviedru loma mazāko privilēģiju principā

Ja mēs nopietni uztveram domu, ka katram lietotājam vajadzētu būt tikai stingri nepieciešamajām atļaujām, tad sudo kļūst par zvaigžņu rīksKnifs nav "likt sudo visa priekšā", bet gan izstrādāt saprātīgu /etc/sudoers politiku, kas pielāgota jūsu reālajām vajadzībām.

Piemēram, lietotājam, kuram nginx jāspēj restartēt tikai tad, kad pakalpojums nedarbojas, nav obligāti jāspēj instalēt pakotnes vai modificēt citus pakalpojumus. Varat izveidot noteikumus, kas atļauj tikai noteiktas darbības. sudo systemctl restart nginx un liegt tādas komandas kā `systemctl stop nginx` vai `apt install`. Līdzīgi noteiktiem lietotājiem var piešķirt atļauju veidot un dzēst direktorijus (izmantojot `/bin/mkdir` un `/bin/rm`), bet ne modificēt neko sensitīvāku.

Milzīga Sudo priekšrocība ir tā, ka atļauju piešķiršana un atsaukšana ir ļoti granulēts un atgriezenisksJa kādam vairs nav paaugstinātu privilēģiju, vienkārši noņemiet viņu no sudoers grupas vai izdzēsiet/pielāgojiet viņa ierakstu sudoers; nav nepieciešams mainīt globālās paroles vai koordinēt darbības ar citiem administratoriem, lai pārdalītu saknes atslēgas.

Arī sudo atstātais žurnāls ir nenovērtējams: katra izpilde ir saistīta ar konkrētu lietotāju, tostarp laiks, TTY, precīza komanda un, paplašinātās konfigurācijās, pat standarta un kļūdu izvade, kas tiek ierakstīta īpašā žurnālā. Profesionālā vidē tas ievērojami vienkāršo izmaiņu auditēšanu un incidentu izmeklēšanu.

Tāpēc datoros ar vairākiem administratoriem vai serveros, kuriem var piekļūt no interneta, Pareizi konfigurēta sudo izmantošana parasti ir vissaprātīgākā iespēja.Vienmēr strādājot kā tiešajam root lietotājam vai deleģējot privilēģijas, izmantojot sakni, bez rūpīgas pielāgošanas, bieži vien tiek pārkāpts mazāko privilēģiju princips, kā arī tiek sarežģīta drošība un izsekojamība.

Riski, kas saistīti ar sviedru atstāšanu "tādā veidā, kā tie nāk"

Tagad seko nepatīkamākā daļa: lai gan svīšana ir lielisks līdzeklis, Atstājot to tādā stāvoklī, kā tas ir pēc noklusējuma, var rasties drošības ievainojamība.Daudzas izplatības to instalē un aktivizē automātiski, piešķirot galvenajam lietotājam gandrīz līdzvērtīgas tiesības kā pilnām root tiesībām.

Tipisks piemērs ir slavenais labvēlības periods Runājot par paroli. Pēc noklusējuma pēc paroles ievadīšanas sudo to vairs neprasa vairākas minūtes (parasti 5 vai 15, atkarībā no versijas). Tas ir ļoti ērti, ja tiek apvienotas administratora komandas, taču tas arī paver iespēju kādam izmantot atbloķētu sesiju un iegūt root piekļuvi, nezinot paroli.

Vēl viens jutīgs punkts ir konfigurācijas, ko tie izmanto. NOPASSWD To var izdarīt diezgan nejaušā veidā, ļaujot lietotājam vai grupai izpildīt jebkuru komandu ar `sudo` bez nepieciešamības autentificēties. Šī konfigurācija varētu būt noderīga ļoti specifiskos skriptos vai automatizētās vidēs, taču, ja to piemēro parastam lietotāja kontam, tā daudzkārt palielina jebkādas ievainojamības izmantošanas vai sesijas nolaupīšanas ietekmi.

Nevajadzētu aizmirst, ka arī pašiem sviedriem ir bijusi drošības ievainojamības Gadu gaitā daudzas no šīm ievainojamībām varēja izmantot tikai tad, ja bija pieejams sudo un, jo īpaši, ja tas bija konfigurēts brīvi. Dažos gadījumos konservatīvas konfigurācijas vai pilnīga sudo neesamība atstāja noteiktas sistēmas neietekmētas no šīm ievainojamībām.

Šādu lietu dēļ daži administratori, pat atzīstot sudo lietderību, dod priekšroku, lai viņu pastāvīgais lietotājs nav pilnīgas piekļuves un administratīviem uzdevumiem viņi izvēlas strādāt ar klasisko root piekļuvi. Izplatījumos, kuros pēc noklusējuma ir iespējota sudo, ir diezgan bieži redzēt administratorus, kuri iestata root paroli, atsauc sudo piekļuvi ikdienas lietotājam failā /etc/sudoers un atstāj bināro failu instalētu, bet bez efektīvām privilēģijām.

Pretējā galējībā ir tie, kas apgalvo, ka problēma nav sviedri, bet gan nav pareizi konfigurētsCitiem vārdiem sakot, stingra sudo politika (bez plaši izplatītas NOPASSWD, bez gariem labvēlības periodiem, ar ierobežotām komandām) piedāvā lielāku drošību nekā plaši izplatīta tiešas root piekļuves izmantošana. Praktiska pieredze daudzās organizācijās stingri apstiprina šo viedokli.

Kā sacietēt sviedrus, neļaujot sevi satraukt paroles dēļ

Ja vēlaties turpināt lietot sudo, bet samazināt tā riskus, ir vairāki diezgan efektīvi pasākumi, ko varat veikt, modificējot failu /etc/sudoers (vienmēr ar Visudo(To nevar atvērt tieši ar jebkuru redaktoru).

Pirmais ir kontrolēt timestamp_timeoutTas nosaka, cik minūtes ilgst labvēlības periods. Iestatot `defaults` uz `timestamp_timeout=0`, `sudo` katru reizi, kad tas darbojas, pieprasa paroli, neko neatceroties. Tā ir visparanoiskākā opcija, bet arī visdrošākā, jo tā novērš risku, ka kāds cits varētu izmantot jūsu atvērto sesiju.

Ja tas šķiet pārāk neērti, varat izvēlēties saprātīgu kompromisu, piemēram, `Defaults timestamp_timeout=1`, kas autentifikāciju saglabā tikai vienu minūti. Praktiski, veicot ātru pielāgošanu, jūs joprojām izvairāties no paroles ievadīšanas divdesmit reizes pēc kārtas, taču ievērojami samazināsiet uzbrukuma logu uzmanības noplūdi gadījumā.

Vēl viens ļoti ieteicams pasākums ir ierobežot īpaši sensitīvas komandasPiemēram, Debian līdzīgās sistēmās jūs varētu liegt `sudo` grupas dalībniekiem mainīt root paroli, pievienojot kaut ko līdzīgu: `%sudo ALL=(ALL) ALL, !/usr/bin/passwd root`. RHEL/Fedora vidē jūs varētu izmantot `wheel` grupu līdzīgā veidā.

Ir iespējams arī definēt īpašas opcijas katram lietotājam, resursdatoram, komandai vai grupai, izmantojot noklusējuma direktīvu dažādos līmeņos. Varat piespiest noteiktas komandas darboties tikai no interaktīva pseidotermināļa, definēt pielāgotu žurnālfailu sudo darbībām, pielāgot faila izveides masku (umask), izpildot privileģētas komandas, vai mainīt kļūdas ziņojumu, ja kāds ievada nepareizu paroli.

Ja vēlaties spert soli tālāk, sudo pat ļauj reģistrēt komandas izvadi (log_output), precīzi pielāgot ceļu, kas tiek izmantots, palaižot lietas kā root (secure_path), vai neļaut programmai, kas palaista ar sudo, atvērt citu čaulu ar tādām pašām privilēģijām (NOEXEC). Pareizi lietojot, tas viss palīdz samazināt gan cilvēcisku kļūdu, gan privilēģiju ļaunprātīgas izmantošanas risku.

Kad izvairīties no sudo un izvēlēties root vai su

Ņemot vērā visu iepriekš minēto, ir pamatoti jautāt, vai pastāv scenāriji, kuros tam ir jēga izvairīties no svīšanas vai gandrīz pilnībā iztikt bez tāsGodīga atbilde ir jā, lai gan tie nav visizplatītākie.

Ļoti specifiskos serveros, kurus pārvalda viens pieredzējis administrators un bez "vidējā līmeņa" lietotājiem, var būt pieņemami vienmēr strādāt kā root lietotājam vai izmantojot `su`, atspējojot vai pat atinstalējot `sudo`. Pamatojums ir tāds, ka tas samazina uzbrukuma virsmu, kas izriet no iespējamām sudo ievainojamībām, un novērš kārdinājumu piešķirt pseido-root privilēģijas kontiem, kuriem tās nav nepieciešamas.

Ir arī administratori, kas dod priekšroku radikāli atdalīt savas identitātes: visam pārējam viņi izmanto savu parasto kontu un personīgajām lietām tikai savu personīgo kontu. Viņi piesakās kā root, lai veiktu root uzdevumus.bez iespējas izmantot sudo no parastā konta. Tādā veidā, ja jūsu neprivileģētais lietotāja konts ir apdraudēts vai kādai no jūsu lietojumprogrammām ir drošības kļūda, uzbrucējs nevar iegūt root piekļuvi ar nekontrolētu sudo komandu.

Tomēr šai pieejai ir būtiski trūkumi. Sistēmās, kurās sadarbojas vairāki cilvēki, mēs atgrieztos pie problēmas ar root paroles koplietošanu un nespēju to selektīvi atsaukt. Un, ja ir atļauta attālā root pieteikšanās, izmantojot SSH, tas paver ļoti vilinošu mērķi brutāla spēka uzbrukumiem un akreditācijas datu zādzībām.

Otrā galējībā ir tie, kas uzskata, ka patiesi nedroša ir atteikšanās no sudo, jo tas veicina pārmērīgu root tiesību izmantošanu un apgrūtina neiespējami ierobežot konkrētas darbības vai arī katram lietotājam ir detalizēti žurnāli. Daudzi reāli pārkāpumi ir bijuši vairāk saistīti ar koplietotām root parolēm un neuzmanīgi izpildītām bīstamām komandām, nevis ar pareizu sudo lietošanu.

Galu galā sudo neizmantošanas lietderība lielā mērā būs atkarīga no konteksta: personālajos datoros vai viena lietotāja serveros "klasiskā root" pieeja var būt jēgpilna, ja zināt, ko darāt, un ievērojat labas prakses (spēcīgas paroles, pareizi konfigurēts SSH, bez grafiskas pieteikšanās kā root utt.). Vairāku lietotāju vai uzņēmumu vidēs Atteikšanās no svīšanas parasti ir slikta ideja. jo jūs zaudējat galvenos kontroles un audita rīkus.

Instalējiet, konfigurējiet un pārbaudiet sudo privilēģijas

Vairumā mūsdienu izplatījumu sudo nāk iepriekš instalēts un darbojasJa, mēģinot to izmantot, redzat ziņojumu “komanda nav atrasta”, jums būs jāveic šāda darbība: Instalējiet to, izmantojot pakotņu pārvaldnieku atbilstoši: apt Debian/Ubuntu vidē, yum vai dnf CentOS/RHEL/Fedora vidē, zypper SLES/openSUSE vidē utt. Parasti šis modelis ir kaut kas līdzīgs apt install sudo vai dnf install sudo ar atbilstošām atļaujām.

Kad tas ir instalēts, ir pienācis laiks izlemt. Kas var izmantot sudo un kāIr divas galvenās pieejas: tieša /etc/sudoers rediģēšana ar visudo, lai pievienotu konkrētus noteikumus, vai spēlēšanās ar īpašām grupām, piemēram, sudo (Debian/Ubuntu sistēmās) vai wheel (Red Hat pasaulē) un definējiet politikas pa grupām sudoers sistēmā.

Visudo ir svarīgs, jo tas bloķē failu rediģēšanas laikā un pārbauda sintaksi saglabāšanas laikā. Ja pieļaujat kļūdu un pārkāpjat sintaksi, izmaiņas netiks lietotas, tādējādi novēršot sudo nederīgumu. Atcerieties, ka /etc/sudoers parasti var lasīt tikai root lietotājs, un šīs atļaujas ir jāievēro, lai citi lietotāji nevarētu to izsekot vai mēģināt modificēt.

Sudoers failā var definēt lietotāju, resursdatoru, komandu un izpildes grupu aizstājvārdi (Runas_Alias) Lai vienkāršotu noteikumus, iestatiet globālas vai specifiskas opcijas (noklusējuma vērtības) un pēc tam izveidojiet pašus piekļuves noteikumus: stila rindas user host = (users:groups) command1, command2 utt. PASSWD un NOPASSWD tagi kontrolē, vai tiek pieprasīta parole, savukārt EXEC un NOEXEC kalpo, lai ierobežotu komandu atvērt pakārtotas čaulas ar tādām pašām privilēģijām.

Vēl viens veids, kā piešķirt privilēģijas, ir pievienot lietotāju grupai `sudo` vai `wheel` ar komandu, piemēram, `sudo usermod -aG sudo username`. Turpmāk lietotājs mantos šai grupai `sudoers` definēto politiku, kas pēc noklusējuma parasti ļauj palaist jebkuru komandu kā root pēc autentifikācijas, lai gan ieteicams to pārskatīt un pielāgot atbilstoši savām vajadzībām.

Lai precīzi pārbaudītu, ko sudo konts var darīt, jums ir iespēja -l (saraksts)Izpildot komandu `sudo -l`, jūs redzēsiet, kuras komandas jums ir atļauts izmantot, kādi konkrēti noklusējuma iestatījumi attiecas uz jūsu lietotāju un vai jums ir kādi īpaši ierobežojumi. Izmantojot komandu `sudo -l -U another_user`, priviliģēts administrators var skatīt citu kontu faktisko konfigurāciju.

Izplatījumos, kuros sudo nav iespējots pēc noklusējuma vai kuros vēlams to ierobežot, ieteicams pārskatīt arī -uy un -g izmantošanu, kas ļauj palaist komandas kā citam lietotājam vai grupai, ja sudoers to atļauj, kā arī -e opciju, kas ir noderīga failu rediģēšanai ar konkrētu redaktoru privileģētā kontekstā.

Lietojot sudo ikdienā, ir vērts atcerēties tādas opcijas kā -v (lai atsvaidzinātu skaitītāju un pagarinātu labvēlības periodu) vai -k (lai nekavējoties anulētu autentifikāciju un piespiestu nākamo sudo komandu pieprasīt paroli). Izmantojot šīs opcijas saprātīgi, tās palīdz panākt līdzsvaru starp paroles ievadīšanas novēršanu ik pēc piecām sekundēm un bīstami "karstu" sesiju novēršanu.

Aplūkojot visu paketi — tiešu root piekļuvi, su, pareizi vai nepareizi konfigurētu sudo, aizstājvārdus, labvēlības periodus, izsekojamību —, kļūst skaidrs, ka patiesa drošība nav atkarīga no viena rīka, bet gan no tā, kā tie visi sader kopā. Izvēloties parasto lietotāju kā galveno kontu, izmantojot Es svīstu ar stingru politiku un bez pārlieku pašpārliecinātībasSudoeru un root piekļuves rezervēšana īpašiem gadījumiem un bieža sudoeru un žurnālu pārbaude ir diezgan stabils veids, kā kontrolēt sistēmas, nepārvēršot Linux par nepārtrauktu paroļu pārbaudi vai krievu ruletes spēli ar rm -rf komandām.