Gentoo Hardened vs andere distributies

Het zit allemaal in de bron! Gentoo hardened is een security-gedreven distro het geharde profiel echt pakt veel in om het echt veilig te maken.

Maar is het de moeite waard om te compileren? Een grote vraag onder de linux-forums.

Laten we eens kijken naar het versterkte profiel van Gentoo in termen van veiligheid:

terwijl het wat secu maar het is zo weinig dat het het in de meeste gevallen niet waard is. Het biedt meer veiligheid op een binaire distro omdat iedereen dezelfde binaire bestanden heeft en een aanvaller niet hoeft te raden waar een specifiek stuk code kan worden geladen, maar door een broncode uit te voeren is je adresruimte al vrij uniek. Het enige geval waarin het biedt enige beveiliging wanneer een aanvaller een adres voor een exploit probeert te raden, als een verkeerde gok het proces doet crasht het proces en wordt het opnieuw geladen op een nieuw adres. Heeft u voldoende waardevolle gegevens voor een aanvaller om dat te doorstaan gedoe om het te krijgen? Als je dat doet, zou je een versterkt profiel moeten gebruiken, maar fysieke beveiliging en schijfversleuteling is belangrijker, want als het zoveel waard is, is het gemakkelijker om je gewoon te beroven.

Houd er rekening mee dat er geen verhard desktopprofiel is, dus alleen dat maakt het wat moeilijker als je het op een desktop wilt gebruiken.

Een andere reden is als je zoiets als SELinux wilt gebruiken (waarvoor geen verhard profiel nodig is) dat je zeer fijnmazige controle geeft over toegangscontrole, maar het is ook erg beperkend. Ik denk dat het alleen de moeite waard is voor grote netwerken met veel gebruikers en verschillende toegangsniveaus tot gevoelige gegevens.

Ik had een aantal SELinux-functies nodig, maar nam genoegen met het gebruik van AppArmor op een ongebruikelijke manier om ze te bereiken, omdat SELinux is teveel moeite. Het enige dat AppArmor echt doet, is procesisolatie of sandboxing bieden. Als een aanvaller toegang krijgt via een exploint, heeft hij alleen toegang tot de bestanden waartoe de uitgebuite service toegang heeft. Ik gebruik het met een catch all-profiel dat voorkomt uitvoering vanuit alle beschrijfbare mappen en homedirectorys en toegang tot ssh / pgp-sleutels, sleutelhangers, enz. Dit werkt goed voor servers en desktops en is niet te beperkend. En als ik code moet uitvoeren vanuit mijn thuismap voor ontwikkeling, kan ik start een onbeperkte shell via sudo. Ik kan mijn laptop ontgrendeld laten met de portemonnee open (ik gebruik de kwallet pam-module) en het zal heel moeilijk voor je zijn om zoiets als ssh-sleutels of wachtwoorden te krijgen (ik heb ook patches voor kwallet, dus vereist een passw ord om opgeslagen wachtwoorden te tonen), maar de programmas die ze nodig hebben, hebben er toegang toe.

Maar wat maakt het hard? laten we ook eens kijken naar enkele van die items:

• PaX is een kernelpatch die ons beschermt tegen stack en heap-overflows. PaX doet dit door ASLR (Address Space Layout Randomization) te gebruiken, dat willekeurige geheugenlocaties in het geheugen gebruikt. Elke shellcode moet een adres gebruiken om erin te springen om code-uitvoering te krijgen en omdat het adres van de buffer in het geheugen willekeurig is, is dit veel moeilijker te bereiken. PaX voegt een extra beschermingslaag toe door de gegevens die door het programma worden gebruikt in een niet-uitvoerbaar geheugengebied te bewaren, wat betekent dat een aanvaller de code die hij in het geheugen heeft geschreven, niet kan uitvoeren. Om PaX te gebruiken, moeten we een PaX-enabled kernel gebruiken, zoals hardened-sources.
• PIE / PIC (positie-onafhankelijke code): Normaal gesproken heeft een uitvoerbaar bestand een vast basisadres waar ze zijn geladen. Dit is ook het adres dat aan de RVAs wordt toegevoegd om het adres van de functies in het uitvoerbare bestand te berekenen. Als het uitvoerbare bestand is gecompileerd met PIE-ondersteuning, kan het overal in het geheugen worden geladen, terwijl het op een vast adres moet worden geladen als het zonder PIE-ondersteuning is gecompileerd. De PIE moet worden ingeschakeld als we PaX willen gebruiken om te profiteren van ASLR.
• RELRO (relocation read-only): wanneer we het uitvoerbare bestand uitvoeren, moet het geladen programma in sommige secties schrijven die niet Het hoeft niet te worden gemarkeerd als beschrijfbaar nadat de toepassing is gestart. Dergelijke secties zijn .ctors, .dtors, .jcr, .dynamic en .got [4].Als we die secties markeren als alleen-lezen, kan een aanvaller bepaalde aanvallen niet gebruiken die kunnen worden gebruikt om code-uitvoering te krijgen, zoals het overschrijven van items in een GOT-tabel.
• SSP ( stack-smashing protector) wordt gebruikt in gebruikersmodus; het beschermt tegen overlopen van de stapel door een kanarie op de stapel te plaatsen. Wanneer een aanvaller het retour-EIP-adres op de stapel wil overstromen, moet hij ook de willekeurig gekozen kanarie overstromen. Wanneer dat gebeurt, kan het systeem detecteren dat de kanarie is overschreven, in welk geval de toepassing wordt beëindigd, waardoor een aanvaller niet naar een willekeurige locatie in het geheugen kan springen en vanaf daar code kan uitvoeren.
• RBAC (op rollen gebaseerde toegangscontrole): Merk op dat RBAC niet hetzelfde is als RSBAC, die we later zullen presenteren. De RBAC is een toegangscontrole die kan worden gebruikt door SELinux, Grsecurity, etc. Standaard heeft de maker van een bestand volledige controle over het bestand, terwijl de RBAC de rootgebruiker dwingt om controle te hebben over het bestand, ongeacht wie het bestand heeft aangemaakt. het. Daarom moeten alle gebruikers op het systeem de RBAC-regels volgen die zijn ingesteld door de systeembeheerder.

Bovendien kunnen we ook de volgende toegangscontrolesystemen gebruiken, die worden gebruikt om de toegang tussen processen en voorwerpen. Normaal gesproken moeten we een van de onderstaande systemen kiezen, omdat er maar één van de toegangscontrolesystemen tegelijk kan worden gebruikt. Toegangscontrolesystemen omvatten het volgende:

• SELinux (beveiligde Linux)
• AppArmor (applicatiebepantsering)
• Grsecurity, dat verschillende patches bevat die kan op de kernel worden toegepast om de beveiliging van een heel systeem te vergroten. Als we Grsecurity in de kernel willen inschakelen, moeten we een voor Grsecurity ingeschakelde kernel gebruiken, die hardened-sources is.
• RSBAC (rule set-based access control): We moeten rsbac-sources kernel gebruiken om een kernel te bouwen met rsbac-ondersteuning.

Het komt allemaal neer op de grote vraag zoals eerder vermeld? De moeite waard om te compileren? Komt echt neer op hoe of wat je beveiligt en is de moeite de moeite waard? Of zul je echt kunnen beveiligen wat je niet wilt dat nieuwsgierige blikken zien?

Opmerkingen

• Oké, bedankt voor de opheldering van alle deze beveiligingstechnologieën. Dus als ik je punt begrijp, zijn deze items erg handig om de beveiliging van een systeem te verbeteren; maar je vraagt " is het de moeite waard om te compileren? ". Dus waarom zijn ze niet standaard ingeschakeld in sommige grote distributies? Ik las dat PaX op een desktop sommige binaire bestanden kan breken (gehoord van java of firefox); is het de enige reden?
• De reden dat PaX en grsecurity niet de standaard zijn op veel distributies, is te wijten aan politiek en egos. De ontwikkelaars van beide hebben persoonlijkheden die sterk botsen met het Linux-kernelontwikkelteam. Bovendien willen ze niet de tijd nemen om hun patch op te splitsen in brokken die stroomopwaarts zouden worden geaccepteerd, en in plaats daarvan hun tijd gebruiken om meer beveiligingsfuncties te ontwikkelen.
• Merk ook op dat grsecurity is geen toegangscontrolesysteem. Spender (maker van grsecurity) raakt erg geïrriteerd als mensen het een toegangscontrolesysteem noemen en het dan vergelijken met SELinux. : P Grsecurity is een combinatie van kernelpatches die de kernelbeveiliging verhoogt door bugklassen te elimineren. Het RBAC-toegangscontrolesysteem dat het heeft, is onbeduidend in vergelijking met de rest. Grsecurity ' s beveiligingsfuncties zijn zo uitgebreid dat het veel meer ruimte in beslag zou nemen dan in een enkele post zou kunnen worden gestopt. Bekijk grsecurity.net voor een behoorlijk uitgebreide lijst.
• hoewel het enige beveiliging toevoegt, is het ' zo weinig dat het ' is het in de meeste gevallen niet waard – Uh, dit is volkomen onjuist. En de beveiliging heeft helemaal niets te maken met onderduikadressen. Ik ' m verbaasd dat dit antwoord positief is.