Gentoo Hardened vs andra distros

Det är allt i källan! Gentoo härdad är en säkerhetsdriven distro den härdade profilen verkligen paketerar mycket för att göra det riktigt säkert.

Men är det värt att sammanställa? En stor fråga bland Linuxforum.

Låt oss titta på Gentoo härdade profil när det gäller säkerhet:

medan det lägger till lite secu det är så lite att det i de flesta fall inte är värt det. Det ger mer säkerhet i en binär distro eftersom alla har samma binärfiler och en angripare behöver inte gissa var en specifik kod kan laddas men genom att köra en källfördelning är ditt adressutrymme redan ganska unikt. Det enda fallet där det ger viss säkerhet när en angripare försöker gissa en adress för en exploatering, att göra en fel gissning kommer sannolikt att krascha processen och den kommer att laddas om till en ny adress. Har du tillräckligt med värdefull information för att en angripare ska kunna gå igenom det krångel för att få det? Om du gör det bör du använda en härdad profil, men fysisk säkerhet och diskkryptering är viktigare för om det är värt så mycket är det lättare att bara råna dig.

Var medveten om att det inte finns någon härdad skrivbordsprofil så att det ensamma gör det något svårare om du planerar att använda det på ett skrivbord.

En annan anledning är om du vill använda något som SELinux (som inte kräver en härdad profil) som ger dig mycket finkornig kontroll om åtkomstkontroll men det är också mycket begränsande. Jag tycker att det bara är värt det för stora nätverk med många användare och olika nivåer av åtkomst till känslig data.

Jag behövde några av SELinux-funktionerna men nöjde mig med att använda AppArmor på ett ovanligt sätt för att uppnå dem eftersom SELinux är för mycket besvär. Allt som AppArmor verkligen gör är att tillhandahålla processisolering eller sandboxning. Om en angripare får åtkomst genom en exploint kommer han bara att kunna komma åt de filer som den exploaterade tjänsten har tillgång till. Jag använder den med att fånga all profil som förhindrar exekvering från alla världsskrivbara och hemkataloger, och tillgång till ssh / pgp-nycklar, nyckelringar etc. Detta fungerar bra för servrar och skrivbord och är inte alltför begränsande. Och om jag behöver köra kod från mitt hem för utveckling kan jag starta ett obegränsat skal via sudo. Jag kan lämna min bärbara dator olåst med plånboken öppen (jag använder kwallet pam-modulen) och det blir väldigt svårt för dig att få något som ssh-nycklar eller lösenord (jag har också lappar för kwallet så det kräver en passw ord för att visa sparade lösenord), men de program som behöver dem har åtkomst till dem.

Men vad gör det härdat? Låt oss titta på några av dessa objekt också:

• PaX är en kärnkorrigering som skyddar oss från stack- och heapöverflöden. PaX gör detta genom att använda ASLR (randomisering av adressutrymme layout), som använder slumpmässiga minnesplatser i minnet. Varje skalkod måste använda en adress för att hoppa till inbäddad i den för att få kodkörning, och eftersom adressen till bufferten i minnet är randomiserad är det mycket svårare att uppnå. PaX lägger till ytterligare ett skydd genom att hålla de data som används av programmet i en icke-körbar minnesregion, vilket innebär att en angripare inte kommer att kunna köra koden som det lyckades skriva i minnet. För att kunna använda PaX måste vi använda en PaX-aktiverad kärna, till exempel härdade källor.
• PIE / PIC (positionsoberoende kod): Normalt har en körbar en fast basadress där de är laddade. Detta är också adressen som läggs till RVA för att beräkna adressen för funktionerna i den körbara filen. Om den körbara filen är kompilerad med PIE-stöd kan den laddas var som helst i minnet, medan den måste laddas på en fast adress om den kompileras utan PIE-stöd. PIE måste aktiveras om vi vill använda PaX för att dra nytta av ASLR.
• RELRO (omlokalisering skrivskyddad): När vi kör den körbara, måste det laddade programmet skriva in i några avsnitt som inte behöver inte markeras som skrivbar efter att applikationen startades. Sådana avsnitt är .ctors, .dtors, .jcr, .dynamic och .got [4].Om vi markerar dessa avsnitt som skrivskyddade kan en angripare inte använda vissa attacker som kan användas när de försöker få kodkörning, till exempel att skriva över poster i en GOT-tabell.
• SSP ( stack-smashing protector) används i användarläge; det skyddar mot överflöd genom att placera en kanariefågel på stacken. När en angripare vill överflöda retur-EIP-adressen på stacken, måste han också rinna över den slumpmässigt valda kanariefågeln. När det händer kan systemet upptäcka att kanariefågeln har skrivits över, i vilket fall applikationen avslutas och därmed inte tillåta en angripare att hoppa till en godtycklig plats i minnet och köra kod därifrån.
• RBAC (rollbaserad åtkomstkontroll): Observera att RBAC inte är detsamma som RSBAC, vilket vi presenterar senare. RBAC är en åtkomstkontroll som kan användas av SELinux, Grsecurity, etc. Som standard har skaparen av en fil total kontroll över filen, medan RBAC tvingar rotanvändaren att ha kontroll över filen, oavsett vem som skapade den. Därför måste alla användare i systemet följa de RBAC-regler som ställts in av systemadministratören.

Dessutom kan vi också använda följande åtkomstkontrollsystem, som används för att kontrollera åtkomst mellan processer och föremål. Normalt måste vi välja något av de system som beskrivs nedan, eftersom endast ett av åtkomstkontrollsystemen kan användas åt gången. Åtkomstkontrollsystem inkluderar följande:

• SELinux (säkerhetsförbättrad Linux)
• AppArmor (applikationsskydd)
• Grsecurity, som innehåller olika korrigeringar som kan appliceras på kärnan för att öka säkerheten för ett helt system. Om vi vill aktivera Grsecurity i kärnan måste vi använda en Grsecurity-aktiverad kärna, som är härdade källor.
• RSBAC (regeluppsättningsbaserad åtkomstkontroll): Vi måste använda kärnan rsbac-sources att bygga en kärna med rsbac-stöd.

Allt kommer ner till den stora frågan som tidigare nämnts? Värt att sammanställa? Kommer verkligen ner på hur eller vad du säkrar och är ansträngningen värt att göra? Eller kommer du att kunna säkra det du inte vill att nyfikna ögon ska se?

Kommentarer

• Okej, tack för förtydligandet av alla dessa säkerhetsåtgärder. Så om jag förstår er poäng är dessa artiklar mycket användbara för att förbättra säkerheten i ett system. men du frågar " är det värt att kompilera? ". Så varför är de inte aktiverade som standard i vissa större distros? Jag läste att PaX på ett skrivbord kan bryta några binärer (hört talas om java eller firefox); är det den enda anledningen?
• Anledningen till att PaX och grsecurity inte är standard på många distros beror på politik och ego. Utvecklarna av båda har personligheter som kolliderar starkt med Linux kernel dev-teamet. Utöver det vill de inte ta sig tid att dela upp sin lapp i bitar som skulle accepteras i uppströms, och istället använda tiden för att utveckla fler säkerhetsfunktioner.
• Observera också att grsecurity är inte ett system för åtkomstkontroll. Spender (skapare av grsecurity) blir väldigt irriterad när folk kallar det ett åtkomstkontrollsystem och sedan jämför det med SELinux. : P Grsecurity är en kombination av kärnkorrigeringar som ökar kärnsäkerheten genom att eliminera felklasser. RBAC-åtkomstkontrollsystemet som det har är oväsentligt jämfört med resten. Grsecurity ' s säkerhetsfunktioner är så omfattande att det skulle ta mycket mer utrymme än vad som skulle kunna läggas i ett enda inlägg. Kolla in grsecurity.net för att se en ganska omfattande lista.
• medan det lägger till lite säkerhet är det ' så lite att det ' är inte värt det i de flesta fall – Det här är helt felaktigt. Och säkerheten har egentligen ingenting alls att göra med att dölja adresser. Jag ' är förvånad över att detta svar röstas.