Gentoo Hardened vs other distros

Det er alt i kilden! Gentoo herdet er en sikkerhetsdrevet distro den herdede profilen virkelig pakker mye for å gjøre det virkelig sikkert.

Men er det verdt å samle det? Et stort spørsmål blant linuxforaene.

La oss se på Gentoo-herdet profil når det gjelder sikkerhet:

mens det gir litt sikkerhet det er så lite at det i de fleste tilfeller ikke er verdt det. Det gir mer sikkerhet på en binær distro fordi alle har de samme binærfiler og en angriper ikke trenger å gjette hvor en bestemt kode kan lastes inn, men ved å kjøre en kilde distro er adresseområdet ditt allerede ganske unikt. Det eneste tilfellet der det gir en viss sikkerhet når en angriper prøver å gjette en adresse for en utnyttelse, noe som gir feil gjetning sannsynligvis vil krasje prosessen, og den vil lastes om på en ny adresse. Har du verdifull nok data til at en angriper kan gå gjennom den bryder seg for å få det? Hvis du gjør det, bør du bruke en herdet profil, men fysisk sikkerhet og diskkryptering er viktigere, for hvis det er verdt så mye, vil det være lettere å bare plyndre deg.

Vær oppmerksom på at det ikke er noen herdet skrivebordsprofil, slik at det alene vil gjøre det litt vanskeligere hvis du planlegger å bruke det på et skrivebord.

En annen grunn er at hvis du vil bruke noe som SELinux (som ikke krever en herdet profil) som gir deg veldig finkornet kontroll om tilgangskontroll, men det er også veldig restriktivt. Jeg tror det bare er verdt det for store nettverk med mange brukere og forskjellige nivåer av tilgang til sensitive data.

Jeg trengte noen av SELinux-funksjonene, men nøyde meg med å bruke AppArmor på en uvanlig måte for å oppnå dem fordi SELinux er for mye trøbbel. Alt AppArmor virkelig gjør er å gi prosessisolering eller sandboksing. Hvis en angriper får tilgang gjennom en eksplosjon, vil han bare kunne få tilgang til filene som den utnyttede tjenesten har tilgang til. Jeg bruker den med en fangstprofil som hindrer utførelse fra alle verdensskrivbare kataloger og hjemmekataloger, og tilgang til ssh / pgp-nøkler, nøkkelringer, etc. Dette fungerer fint for servere og stasjonære datamaskiner og er ikke for restriktivt. Og hvis jeg trenger å utføre kode fra hjemmet mitt for utvikling kan jeg lansere et ubegrenset skall via sudo. Jeg kan la den bærbare datamaskinen være ulåst med lommeboken åpen (jeg bruker kwallet pam-modulen), og det vil være veldig vanskelig for deg å få noe som ssh-nøkler eller passord (jeg har også lapper for kwallet så det krever passw ord for å vise lagrede passord), men programmene som trenger dem har tilgang til dem.

Men hva gjør det herdet? la oss se på noen av disse elementene også:

• PaX er en kjerneoppdatering som beskytter oss mot overløp fra stabler og dynger. PaX gjør dette ved å bruke ASLR (randomisering av adresseplassoppsett), som bruker tilfeldige minneplasseringer i minnet. Hver shellcode må bruke en adresse for å hoppe til innebygd i den for å få kodeutførelse, og fordi adressen til bufferen i minnet er randomisert, er dette mye vanskeligere å oppnå. PaX legger til et ekstra beskyttelseslag ved å oppbevare dataene som brukes av programmet, i et ikke-kjørbart minneområde, noe som betyr at en angriper ikke vil kunne utføre koden det klarte å skrive til minnet. For å bruke PaX, må vi bruke en PaX-aktivert kjerne, for eksempel herdede kilder.
• PIE / PIC (posisjonsuavhengig kode): Normalt har en kjørbar en fast baseadresse der de er lastet. Dette er også adressen som legges til RVA-ene for å beregne adressen til funksjonene i den kjørbare filen. Hvis den kjørbare filen er kompilert med PIE-støtte, kan den lastes hvor som helst i minnet, mens den må lastes på en fast adresse hvis den ikke er kompilert uten PIE-støtte. PIE må aktiveres hvis vi vil bruke PaX for å dra nytte av ASLR.
• RELRO (omplassering skrivebeskyttet): Når vi kjører den kjørbare, må det lastede programmet skrive inn i noen seksjoner som ikke Du trenger ikke å merke det som skrivbart etter at applikasjonen ble startet. Slike seksjoner er .ctors, .dtors, .jcr, .dynamic, og .got [4].Hvis vi merker disse delene som skrivebeskyttet, vil en angriper ikke kunne bruke visse angrep som kan brukes når du prøver å få kodeutførelse, for eksempel å overskrive oppføringer i en GOT-tabell.
• SSP ( stack-smashing protector) brukes i brukermodus; det beskytter mot stabeloverløp ved å plassere en kanarifugl på bunken. Når en angriper vil overfylle retur-EIP-adressen på stakken, må han også overflyte den tilfeldig valgte kanarifuglen. Når det skjer, kan systemet oppdage at kanarifuglen er overskrevet, i hvilket tilfelle applikasjonen avsluttes, og dermed ikke tillate en angriper å hoppe til et vilkårlig sted i minnet og utføre kode derfra.
• RBAC (rollebasert tilgangskontroll): Merk at RBAC ikke er det samme som RSBAC, som vi vil presentere senere. RBAC er en tilgangskontroll som kan brukes av SELinux, Grsecurity, etc. Som standard har skaperen av en fil total kontroll over filen, mens RBAC tvinger rotbrukeren til å ha kontroll over filen, uavhengig av hvem som opprettet den. Derfor må alle brukere på systemet følge RBAC-reglene som er satt av administratoren av systemet.

I tillegg kan vi også bruke følgende tilgangskontrollsystemer, som brukes til å kontrollere tilgang mellom prosesser og gjenstander. Normalt må vi velge ett av systemene som er skissert nedenfor, fordi bare ett av tilgangskontrollsystemene kan brukes om gangen. Tilgangskontrollsystemer inkluderer følgende:

• SELinux (sikkerhetsforbedret Linux)
• AppArmor (applikasjons rustning)
• Grsecurity, som inneholder forskjellige oppdateringer som kan brukes på kjernen for å øke sikkerheten til et helt system. Hvis vi ønsker å aktivere Grsecurity i kjernen, må vi bruke en Grsecurity-aktivert kjerne, som er herdede kilder.
• RSBAC (regelsettbasert tilgangskontroll): Vi må bruke rsbac-sources kernel å bygge en kjerne med rsbac-støtte.

Alt kommer ned på det store spørsmålet som nevnt tidligere? Verdt å kompilere? Kommer virkelig ned på hvordan eller hva du sikrer og er innsatsen verdt? Eller vil du kunne sikre det du ikke vil at nysgjerrige øyne skal se?

Kommentarer

• Ok, takk for avklaringen av alle disse sikkerhetshåndhevelsesteknologiene. Så hvis jeg forstår poenget ditt, er disse elementene veldig nyttige for å forbedre sikkerheten til et system; men du spør " er det verdt det å samle? ". Så hvorfor er de ikke aktivert som standard i noen store distroer? Jeg leste at PaX på et skrivebord kan bryte noen binære filer (hørt om java eller firefox); er det den eneste grunnen?
• Årsaken til at PaX og grsecurity ikke er standard på mange distros skyldes politikk og ego. Utviklerne av begge har personligheter som kolliderer sterkt med Linux kernel dev-teamet. I tillegg til det ønsker de ikke å ta seg tid til å dele opp lappen i biter som vil bli akseptert i oppstrøms, og i stedet bruke tiden til å utvikle flere sikkerhetsfunksjoner.
• Vær også oppmerksom på at grsecurity er ikke et adgangskontrollsystem. Spender (skaper av grsecurity) blir veldig irritert når folk kaller det et tilgangskontrollsystem og deretter sammenligner det med SELinux. : P Grsecurity er en kombinasjon av kjernelapper som øker kjernesikkerheten ved å eliminere bugklasser. RBAC-tilgangskontrollsystemet det har, er uvesentlig sammenlignet med resten. Grsecurity ' s sikkerhetsfunksjoner er så omfattende at det vil ta langt mer plass enn det som kan legges i et enkelt innlegg. Sjekk ut grsecurity.net for å se en ganske omfattende liste.
• mens det gir litt sikkerhet, er det ' så lite at det ' er det ikke verdt i de fleste tilfeller – Uh, dette er helt feil. Og sikkerheten har egentlig ingenting å gjøre med skjul adresser. Jeg ' er overrasket over at dette svaret blir oppstemt.