Gentoo Hardened vs andre distros

Det er alt sammen i kilden! Gentoo hærdet er en sikkerhedsdrevet distro den hærdede profil virkelig pakker meget for at gøre det virkelig sikkert.

Men er det værd at kompilere? Et stort spørgsmål blandt linux-fora.

Lad os se på Gentoo-hærdede profil med hensyn til sikkerhed:

mens det tilføjer noget secu det er så lidt, at det i de fleste tilfælde ikke er det værd. Det giver mere sikkerhed på en binær distro, fordi alle har de samme binære filer, og en angriber ikke behøver at gætte, hvor et specifikt stykke kode kan blive indlæst, men ved at køre en kilde distro er dit adresseområde allerede ret unikt. Det eneste tilfælde hvor det giver en vis sikkerhed, når en angriber forsøger at gætte en adresse til en udnyttelse, hvilket gør det forkerte gæt sandsynligvis styrter processen, og det genindlæses på en ny adresse. Har du værdifulde data nok til, at en angriber kan gennemgå det besvær for at få det? Hvis du gør det, skal du bruge en hærdet profil, men fysisk sikkerhed og diskkryptering er vigtigere, for hvis det er så meget værd, er det lettere at bare berøve dig.

Vær opmærksom på, at der ikke er nogen hærdet desktop-profil, så det alene vil gøre det noget sværere, hvis du planlægger at bruge det på et desktop.

En anden grund er, hvis du vil bruge noget i retning af SELinux (som ikke kræver en hærdet profil), der giver dig meget finkornet kontrol om adgangskontrol, men det er også meget restriktivt. Jeg synes, det er kun det værd for store netværk med mange brugere og forskellige niveauer af adgang til følsomme data.

Jeg havde brug for nogle af SELinux-funktionerne, men slog mig til at bruge AppArmor på en usædvanlig måde for at opnå dem, fordi SELinux er for meget besvær. Alt, hvad AppArmor virkelig gør, er at give procesisolering eller sandboxing. Hvis en angriber får adgang gennem en eksplosion, vil han kun kunne få adgang til de filer, som den udnyttede tjeneste har adgang til. Jeg bruger den med en fangstprofil, der forhindrer eksekvering fra alle verdensskrivnings- og hjemmekataloger og adgang til ssh / pgp-nøgler, nøgleringe osv. Dette fungerer godt til servere og desktops og er ikke alt for restriktivt. Og hvis jeg har brug for at udføre kode fra mit hjem dir til udvikling kan jeg lancere en ubegrænset skal via sudo. Jeg kan lade min bærbare computer være ulåst med tegnebogen åben (jeg bruger kwallet pam-modulet), og det vil være virkelig svært for dig at få noget som ssh-nøgler eller adgangskoder (jeg har også patches til kwallet kræver en passw ord for at vise gemte adgangskoder), men de programmer, der har brug for dem, har adgang til dem.

Men hvad gør det hærdet? lad os også se på nogle af disse emner:

• PaX er en kerneopdatering, der beskytter os mod stack og bunkeoverløb. PaX gør dette ved at bruge ASLR (randomisering af adressepladslayout), der bruger tilfældige hukommelsesplaceringer i hukommelsen. Hver shellcode skal bruge en adresse til at springe til indlejret i den for at få kodeudførelse, og fordi adressen på bufferen i hukommelsen er randomiseret, er dette meget sværere at opnå. PaX tilføjer et ekstra beskyttelseslag ved at opbevare de data, der bruges af programmet, i en ikke-eksekverbar hukommelsesregion, hvilket betyder, at en angriber ikke er i stand til at udføre den kode, det lykkedes at skrive i hukommelsen. For at bruge PaX er vi nødt til at bruge en PaX-aktiveret kerne, såsom hærdede kilder.
• PIE / PIC (positionsuafhængig kode): Normalt har en eksekverbar en fast base-adresse, hvor de er indlæst. Dette er også den adresse, der føjes til RVAerne for at beregne adressen på funktionerne inde i den eksekverbare. Hvis den eksekverbare enhed er kompileret med PIE-understøttelse, kan den indlæses hvor som helst i hukommelsen, mens den skal indlæses på en fast adresse, hvis den kompileres uden PIE-understøttelse. PIE skal aktiveres, hvis vi vil bruge PaX til at drage fordel af ASLR.
• RELRO (flytning skrivebeskyttet): Når vi kører den eksekverbare, skal det indlæste program skrive i nogle sektioner, der ikke behøver ikke at blive markeret som skrivbar, efter at applikationen blev startet. Sådanne sektioner er .ctors, .dtors, .jcr, .dynamic og .got [4].Hvis vi markerer disse sektioner som skrivebeskyttet, vil en angriber ikke være i stand til at bruge visse angreb, der muligvis bruges, når de prøver at få kodeudførelse, såsom overskrivning af poster i en GOT-tabel.
• SSP ( stack-smashing protector) bruges i brugertilstand; den beskytter mod stabeloverløb ved at placere en kanariefugl på stakken. Når en angriber ønsker at overløbe retur-EIP-adressen på stakken, skal han også overløbe den tilfældigt valgte kanariefugl. Når dette sker, kan systemet registrere, at kanariefuglen er overskrevet, i hvilket tilfælde applikationen afsluttes, hvilket således ikke tillader en angriber at hoppe til et vilkårligt sted i hukommelsen og udføre kode derfra.
• RBAC (rollebaseret adgangskontrol): Bemærk, at RBAC ikke er det samme som RSBAC, som vi præsenterer senere. RBAC er en adgangskontrol, der kan bruges af SELinux, Grsecurity osv. Som standard har skaberen af en fil total kontrol over filen, mens RBAC tvinger rodbrugeren til at have kontrol over filen, uanset hvem der oprettede det. Derfor skal alle brugere på systemet følge de RBAC-regler, der er indstillet af systemadministratoren.

Derudover kan vi også bruge følgende adgangskontrolsystemer, som bruges til at kontrollere adgang mellem processer og genstande. Normalt skal vi vælge et af nedenstående systemer, fordi kun et af adgangskontrolsystemerne kan bruges ad gangen. Adgangskontrolsystemer inkluderer følgende:

• SELinux (sikkerhedsforbedret Linux)
• AppArmor (applikations rustning)
• Grsecurity, som indeholder forskellige patches, der kan anvendes på kernen for at øge sikkerheden i et helt system. Hvis vi ønsker at aktivere Grsecurity i kernen, skal vi bruge en Grsecurity-aktiveret kerne, som er hærdede kilder.
• RSBAC (regelsætbaseret adgangskontrol): Vi skal bruge rsbac-sources kernel at bygge en kerne med rsbac-understøttelse.

Det hele kommer ned på det store spørgsmål som tidligere nævnt? Værd at kompilere? Kommer virkelig ned på, hvordan eller hvad du sikrer, og er det en anstrengelse værd? Eller vil du være i stand til virkelig at sikre det, du ikke vil have nysgerrige øjne til at se?

Kommentarer

• Okay, tak for afklaringen af alle disse teknologier til håndhævelse af sikkerhed. Så hvis jeg forstår dit punkt, er disse emner meget nyttige til at forbedre sikkerheden i et system; men du spørger " er det værd at kompilere? ". Så hvorfor er de ikke aktiveret som standard i nogle større distroer? Jeg læste, at PaX på et skrivebord kan bryde nogle binære filer (hørt om java eller firefox); er det den eneste grund?
• Årsagen til, at PaX og grsecurity ikke er standard på mange distroer, skyldes politik og egoer. Udviklerne af begge har personligheder, der kolliderer stærkt med Linux kernel dev-teamet. Derudover ønsker de ikke at tage sig tid til at opdele deres patch i klumper, der ville blive accepteret i opstrøms, og i stedet bruge deres tid til at udvikle flere sikkerhedsfunktioner.
• Bemærk også, at grsecurity er ikke et adgangskontrolsystem. Spender (skaberen af grsecurity) bliver meget irriteret, når folk kalder det et adgangskontrolsystem og derefter sammenligner det med SELinux. : P Grsecurity er en kombination af kernepatches, der øger kernesikkerheden ved at eliminere bugklasser. Det RBAC-adgangskontrolsystem, det har, er ubetydeligt sammenlignet med resten. Grsecurity ' s sikkerhedsfunktioner er så omfattende, at det ville tage langt mere plads, end der kunne sættes i et enkelt indlæg. Tjek grsecurity.net for at se en ret omfattende liste.
• mens det tilføjer en vis sikkerhed, er det ' så lidt, at det ' er det ikke værd i de fleste tilfælde – Uh, dette er helt forkert. Og sikkerheden har slet ikke noget at gøre med skjulte adresser. Jeg ' er forbløffet over, at dette svar er opstemt.