Gentoo Hardened vs other distros (Română)

Totul este în sursă! Gentoo hardened este o distribuție bazată pe securitate, profilul întărit într-adevăr împachetează foarte mult pentru a-l face cu adevărat sigur.

Dar merită compilat? O întrebare importantă printre forumurile Linux.

Să analizăm profilul întărit Gentoo din punct de vedere al securității:

în timp ce adaugă câteva secu ritate este atât de puțin încât nu merită în majoritatea cazurilor. Oferă mai multă siguranță pe o distribuție binară, deoarece toată lumea are aceleași binare și un atacator nu trebuie să ghicească unde se poate încărca o anumită bucată de cod, dar executând o distribuție sursă, spațiul dvs. de adresă este deja destul de unic. Singurul caz în care oferă o anumită securitate atunci când un atacator încearcă să ghicească o adresă pentru o exploatare, ceea ce face că presupunerea greșită va prăbuși probabil procesul și va fi reîncărcată pe o nouă adresă. Aveți date suficient de valoroase pentru ca un atacator să treacă problemă pentru a-l obține? Dacă faceți acest lucru, ar trebui să utilizați un profil întărit, dar securitatea fizică și criptarea discului sunt mai importante, deoarece dacă merită atât de mult, va fi mai ușor să vă jefuiți.

Rețineți că nu există un profil de desktop întărit, astfel încât singur va face ceva mai greu dacă intenționați să îl utilizați pe un desktop.

Un alt motiv este dacă doriți să utilizați ceva de genul SELinux (care nu necesită un profil întărit) care vă oferă un control foarte fin asupra controlului accesului, dar este și foarte restrictiv. Cred că merită doar pentru rețelele mari cu mulți utilizatori și diferite niveluri de acces la date sensibile.

Aveam nevoie de unele funcții SELinux, dar m-am mulțumit să folosesc AppArmor într-un mod neobișnuit pentru a le realiza, deoarece SELinux este prea multă problemă. Tot ce face AppArmor este să ofere o izolare a procesului sau un sandbox. Dacă un atacator câștigă acces printr-un exploint, el va putea accesa doar fișierele la care are acces serviciul exploatat. Îl folosesc cu un profil de captură care împiedică execuția din toate directoarele de scriere și home, precum și accesul la chei ssh / pgp, keyrings etc. Acest lucru funcționează frumos pentru servere și desktopuri și nu este prea restrictiv. Și dacă trebuie să execut cod din direcția home pentru dezvoltare, pot lansează un shell nerestricționat prin sudo. Îmi pot lăsa laptopul deblocat cu portofelul deschis (folosesc modulul kwallet pam) și îți va fi foarte greu să obții ceva precum chei ssh sau parole (am și patch-uri pentru kwallet așa că necesită un passw ord pentru a afișa parolele salvate), dar programele care au nevoie de ele au acces la ele.

Dar ce o face să se întărească? să ne uităm și la unele dintre aceste elemente:

• PaX este un patch de nucleu care ne protejează de depășirea stivei și a heap-ului. PaX face acest lucru utilizând ASLR (randomization layout layout randomization), care utilizează locații de memorie aleatorii în memorie. Fiecare shellcode trebuie să utilizeze o adresă pentru a trece la aceasta încorporată pentru a obține executarea codului și, deoarece adresa bufferului din memorie este aleatorie, acest lucru este mult mai greu de realizat. PaX adaugă un strat suplimentar de protecție, păstrând datele utilizate de program într-o regiune de memorie neexecutabilă, ceea ce înseamnă că un atacator nu va putea executa codul pe care a reușit să îl scrie în memorie. Pentru a utiliza PaX, trebuie să folosim un kernel activat PaX, cum ar fi surse întărite.
• PIE / PIC (cod independent de poziție): În mod normal, un executabil are o adresă de bază fixă unde sunt încărcate. Aceasta este, de asemenea, adresa care este adăugată la RVA-uri pentru a calcula adresa funcțiilor din interiorul executabilului. Dacă executabilul este compilat cu suport PIE, acesta poate fi încărcat oriunde în memorie, în timp ce trebuie încărcat la o adresă fixă dacă este compilat fără suport PIE. PIE trebuie activat dacă dorim să folosim PaX pentru a profita de ASLR.
• RELRO (relocare numai în citire): Când rulăm executabilul, programul încărcat trebuie să scrie în unele secțiuni care nu Nu trebuie marcat ca scriibil după ce aplicația a fost pornită. Astfel de secțiuni sunt .ctors, .dtors, .jcr, .dynamic și .got [4].Dacă marcăm acele secțiuni ca doar în citire, un atacator nu va putea folosi anumite atacuri care ar putea fi folosite atunci când încearcă să obțină executarea codului, cum ar fi suprascrierea intrărilor într-un tabel GOT.
• SSP ( stivă-spargere protector) este utilizat în modul utilizator; protejează împotriva revărsărilor stivei prin plasarea unui canar pe stivă. Atunci când un atacator dorește să depășească adresa EIP returnată pe stivă, trebuie să depășească și canarul ales aleatoriu. Când se întâmplă acest lucru, sistemul poate detecta că canarul a fost suprascris, caz în care aplicația este terminată, nepermițând astfel unui atacator să sară într-o locație arbitrară din memorie și să execute cod de acolo.
• RBAC (control acces pe rol): Rețineți că RBAC nu este același cu RSBAC, pe care îl vom prezenta mai târziu. RBAC este un control de acces care poate fi utilizat de SELinux, Grsecurity etc. În mod implicit, creatorul unui fișier are control total asupra fișierului, în timp ce RBAC forțează utilizatorul root să aibă controlul asupra fișierului, indiferent de cine a creat aceasta. Prin urmare, toți utilizatorii din sistem trebuie să respecte regulile RBAC stabilite de administratorul sistemului.

În plus, putem folosi și următoarele sisteme de control al accesului, care sunt utilizate pentru a controla accesul între procese și obiecte. În mod normal, trebuie să alegem unul dintre sistemele prezentate mai jos, deoarece numai unul dintre sistemele de control al accesului poate fi utilizat la un moment dat. Sistemele de control al accesului includ următoarele:

• SELinux (securitate îmbunătățită Linux)
• AppArmor (aplicație armură)
• Grsecurity, care conține diverse patch-uri care poate fi aplicat kernelului pentru a spori securitatea unui întreg sistem. Dacă dorim să activăm Grsecurity în kernel, trebuie să folosim un kernel Grsecurity-enabled, care este hardened-sources.
• RSBAC (control de acces bazat pe set de reguli): trebuie să folosim kernel rsbac-sources pentru a construi un nucleu cu suport rsbac.

Totul se rezumă la marea întrebare așa cum am spus mai devreme? Merită să compilezi? Într-adevăr se rezumă la cum sau la ce vă asigurați și efortul merită? Sau veți putea asigura cu adevărat ceea ce nu doriți să vadă ochii curioși?

Comentarii

• Bine, vă mulțumesc pentru clarificarea tuturor aceste tehnologii de aplicare a securității. Deci, dacă înțeleg punctul dvs., aceste elemente sunt foarte utile pentru a îmbunătăți securitatea unui sistem; dar întrebați " merită să compilați? ". Deci, de ce nu sunt activate în mod implicit în unele distribuții majore? Am citit că PaX pe un desktop poate rupe unele binare (auzit de java sau firefox); este singurul motiv?
• Motivul pentru care PaX și grsecurity nu sunt implicite pentru multe distribuții se datorează politicii și ego-urilor. Dezvoltatorii ambelor au personalități care se ciocnesc puternic cu echipa de dezvoltare a kernel-ului Linux. În plus, nu doresc să-și aloce timpul pentru a-și împărți patch-urile în bucăți care ar fi acceptate în amonte și, în schimb, își folosesc timpul pentru a dezvolta mai multe caracteristici de securitate.
• De asemenea, rețineți că grsecurity este nu un sistem de control al accesului. Cheltuielile (creatorul grsecurity) sunt foarte iritate atunci când oamenii îl numesc un sistem de control al accesului și apoi îl compară cu SELinux. : P Grsecurity este o combinație de patch-uri de nucleu care mărește securitatea nucleului prin eliminarea claselor de erori. Sistemul de control al accesului RBAC pe care îl are este inconsecvent în comparație cu restul. Grsecurity ' caracteristicile de securitate sunt atât de extinse încât ar ocupa mult mai mult spațiu decât ar putea fi pus într-o singură postare. Consultați grsecurity.net pentru a vedea o listă destul de cuprinzătoare.
• în timp ce adaugă o anumită securitate, ' este atât de puțin încât ' nu merită în majoritatea cazurilor – Uh, acest lucru este total incorect. Și securitatea nu are nimic de-a face cu ascunderea adreselor. ' m uimit că acest răspuns este votat în sus.