Cum poate root începe un proces pe care numai root îl poate ucide?

Este ușor să începeți un proces în fundal sau să îl faceți ca systemd serviciu.

Cu toate acestea, dacă vreau să încep un proces care monitorizează activitățile pe mașina Linux, acesta cade în ținta atacurilor.Dacă orice utilizator dorește să facă ceva rău, mai întâi va ucide acest proces, chiar dacă doar este sudoers sau roată utilizatorii, prin simpla execuție ucide sau systemctl stop.

Există vreo modalitate de a aplica un proces numai rădăcină poate ucide?

Băieți, doar să mă gândesc la asta rsyslog serviciul poate fi ucis, ar trebui să recunoașteți cât de vulnerabil este cu adevărat Linux. Este ca și cum un pilot ar putea opri cutia neagră. O companie aeriană permite să se întâmple asta? Sau îi oferă pilotului o listă de permise pentru a-i împiedica să facă orice pentru a salva avionul? Desigur, pilotul poate prăbuși avionul, dar cutia neagră îl va înregistra.

Propunerea mea privind o listă de interdicție este legitimă din perspectiva securității, chiar dacă te poate speria. Deci nu încerca să dai vina pe tipul care a ridicat întrebarea, bine?

Având privilegii nerestricționate sudo/wheel, oricine va putea anula orice ați făcut. Chiar dacă reușiți să realizați acest lucru prin eliminarea posibilității de a ucide direct procesul, de ex. cu sudo ucide, fie acest lucru ar putea fi încă ocolit utilizând alte comenzi sudoed, fie vă blocați și în afara administrării.

Întrebați-vă, de ce utilizatorii neîncrezători au, în primul rând, privilegii sudo nerestricționate? Nu ar trebui. Oferă astfel de privilegii doar celor în care ai încredere totală. Dacă există unele comenzi privilegiate care trebuie încă executate, activați sudo numai pentru acele comenzi:

+netmgr /usr/sbin/ifup, /usr/sbin/ifdown

(utilizare visudo -f /etc/sudoers.d/netmgr pentru a pune acest lucru în fișierul sudoers add-on).

În acest fel, puteți permite unui utilizator să ruleze doar sudo /usr/sbin/ifup și sudo /usr/sbin/ifdown, dar nu alte comenzi sudo. Există o mulțime de alte exemple, instrucțiuni și considerente de securitate man sudoers. Citește!

Auditul se face de obicei în alt mod. În special, ați configurat o alta mașină, configurați-și jurnalul de sistem pentru a accepta jurnalele de la stațiile la distanță. Pe mașina în cauză, configurați înregistrarea, astfel încât să trimită toate jurnalele în mașina de înregistrare, pe lângă stocarea locală. Chiar dacă cineva dezactivează această trimitere a jurnalului, acțiunea de dezactivare în sine va fi înregistrată, așa că cel puțin veți ști cine este vinovat.

Nu poți da cuiva o putere și apoi să-l împiedici să o folosească. Trebuie să concentrezi îndeaproape puterea pe care le-o dai pentru a include doar ceea ce vrei ca ei să aibă.

Intr-un comentariu ai spus:

Trebuie să le permit să folosească ucide sau systemctl stop deoarece există unele aplicații care au nevoie de aceste privilegii isi fac treaba

Asta nu înseamnă acelea utilizatorii au nevoie de acces la acele comenzi, doar la acelea aplicatii. Utilizatorul are permisiuni limitate de rulare sudo ./someprogram și odată ce programul rulează ca root, poate folosi ucide, etc după cum este necesar. Cu toate acestea, utilizatorul nu are acces direct la acele comenzi interne.

În principiu, utilizatorii nu au nevoie de acces la comenzi, au nevoie de acces la funcţionalitate. Dacă ucide este prea riscant, blocați accesul la acesta și oferiți o altă modalitate mai sigură de a obține același rezultat. Poate creați un mic utilitar safekill care actioneaza ca ucide dar refuză cererile de a ucide anumite procese. Oferiți utilizatorilor dvs. acces sudo la safekill dar nu realul ucide. Dacă utilizatorii folosesc întotdeauna aceste comenzi pentru a face același lucru, încapsulați întregul proces într-un program mic și puneți-le să-l folosească în loc să o facă manual (de exemplu, ar rula sudo restart_webservers în loc să omorâți și să reporniți toate diferitele procese de server în mod individual). Utilizatorii dvs. au încă acces la funcționalitățile de care au nevoie, dar nu pot mânui armele periculoase direct.

Există un alt mecanism de aplicare mai extrem, care ar putea fi disponibil în funcție de configurația dvs. specială. Unele procesoare au cronometre de supraveghere disponibil. Modificați programul de monitorizare a activității pentru a porni watchdog-ul și a-l reseta la fiecare două secunde. Dacă cineva reușește să-ți omoare monitorul, timer-ul watchdog ar expira și sistemul se va reporni singur, relansând programul de monitor la pornire. Acest lucru nu ar împiedica strict dezactivarea monitorului, dar ar interzice oricui să facă ceva semnificativ după dezactivarea acestuia. Acest lucru va crea, de asemenea, semnale roșii frumoase în jurnalele de sistem. Majoritatea sistemelor cu watchdog vor raporta când a fost declanșată o anumită repornire de către watchdog. O repornire declanșată de watchdog care are loc în timp ce un utilizator a fost conectat la shell ar trebui să fie văzută ca foarte suspicios.

Linux noob aici. Ați putea să vă gândiți să scrieți programe sau scripturi care fac doar ceea ce acești oameni sunt menționați să facă, apoi să le faceți proprietar de root și să le adăugați bit setuid? Desigur, o mare problemă este că s-ar putea să nu doriți ca alți oameni să execute aceste comenzi. Nu sunt sigur dacă puteți obține informațiile originale despre utilizator. Și, desigur, o grijă suplimentară este întotdeauna necesară cu setuid/setgid.

Dacă dați drept rădăcină unui utilizator liber, atunci utilizatorul ar putea ucide aproape orice. Pentru unele discuții aprofundate și posibile soluții, consultați: unix stack sigkill discuție.

Interesantă este și soluția watchdog menționată de @bta. Există de fapt un pachet software watchdog disponibil, care poate fi configurat pentru a monitoriza schimbarea fișierelor sau pentru a executa un script de utilizator. Cu toate acestea, pe majoritatea nucleelor ​​standard, acest watchdog poate fi oprit de utilizatorul root sau îi puteți modifica configurația. Dar alți utilizatori ar trebui să fie conștienți de acest lucru pentru a o evita. Vedea: https://linux.die.net/man/8/watchdog

Dar dacă nu trebuie să permiteți accesul root complet, dar le puteți gestiona accesul cu mecanismul sudo, atunci puteți seta unele comenzi cu argumente explicite pentru ca acestea să fie executate și să nu permiteți altceva decât drepturile lor implicite de utilizator.

De exemplu, puteți pune /bin/kill în /etc/sudoers fișier, dar permiteți doar argumente specifice.

bob ALL=(rădăcină) /bin/kill -sigTERM [1-9][0-9][0-9][0-9]

Acest lucru ar permite utilizatorului bob a executa /bin/kill, dar omorâți numai procesele cu un PID între 1000 și 9999. Dacă executați monitorul suficient de devreme, acesta va avea un PID scăzut și nu va putea fi ucis în acest fel. Utilizator bob s-ar putea încurca în continuare cu tine ucigându-ți propriile procese de utilizator, desigur... și, cu împachetarea PID, acest lucru poate să nu fie prea util oricum.

Este posibil să scadă anumite opțiuni dintr-un set complet. De exemplu, ucideți toate PID-urile nenegative, dar nu permiteți semnalizarea unui PID care conține 1337 și nu permiteți -1 uciderea.

bob ALL=(rădăcină) /bin/kill -sigTERM *,!/bin/kill *1337*,!bin/kill *-1*

Dar asta ar fi puțin ciudat și ai fi fost foarte sigur că programul nu-și înglobează intrările. Procps kill nu face parte din câte văd, dar acest exemplu ar permite totuși uciderea unui proces cu pid 1337 dacă a făcut parte dintr-un grup de procese al cărui lider nu era. Deci, acest lucru arată cât de dificil este să lucrezi cu negative sau liste negre.

Opțiune mai bună, permiteți doar să ucideți anumite procese după nume

bob ALL=(rădăcină) /usr/bin/pkill -sigTERM -f namedprocess

Sau doar reporniți un anumit serviciu

bob ALL=(rădăcină) /bin/systemctl reporniți a-service

Utilizatorul poate vizualiza comenzile sudo disponibile cu sudo -l

Este important dacă permiteți anumitor programe să le specifice calea completă. Și, de asemenea, utilizatorul nu trebuie să aibă drepturi de deconectare sau de editare pe acel program sau ar putea fi înlocuit cu altceva.

Am venit cu A Start!

rădăcină poate seta un SHELL DEFAULT pentru un utilizator ca acesta:

useradd [un utilizator] -s [un anumit executabil]

Atunci, dacă un anumit executabil = Un script de cenzură care:

1. Cenzurează automat anumite comenzi pentru a fi executate. Ca Stop & rsyslog combinate.

2. comenzile bans pentru a scăpa de acest shell și pentru a utiliza un altul chiar și originalul bash

3. interzice comenzile pentru a împiedica utilizatorul să obțină rolul rădăcină ca ceea ce @user253751 a menționat mai sus.

4. Transmiteți restul comenzilor către /bin/bash

Apoi doar setează-l r+x pentru orice utilizator.

Orice sugestie este apreciată sub acest răspuns. Mai ales pentru 2 & 3 par diverse mijloace.

Bash va încărca setările în /etc/profile și /etc/bashrc primul. Am observat că ultimele se referă la PROMPT_COMMAND variabil. Este posibil să deturnați acest lucru la ultima linie a acestuia pentru a adăuga în scriptul de cenzură, dar este necesar un nume de utilizator de exceptare pentru unele sisteme, deoarece în mod implicit nimeni nu are privilegiul de root pentru a-l schimba înapoi.

O cenzură completă care satisface 4+1 de mai sus va fi marcată ca răspuns legitim.

Nu voi marca niciodată un răspuns „vei să renunți” ca fiind legitim.

întrebările conexe sunt:

Cum pot înregistra comenzile bash ale utilizatorilor?

Cum pot face bash to log comenzi shell la syslog?

Conectați-vă fără a rula bash_profile sau bashrc