Policies en voordelen
De SE Linux-configuratie wordt beschreven in modulaire policies. De kern van deze policies wordt tegenwoordig steeds vaker gevormd door de zogenaamde Reference Policy. Dit is een set met universele definities voor de meest voorkomende onderdelen van het systeem, zoals netwerktoegang of toegang tot de kernel. Nieuwe applicaties met nieuwe modules kunnen eenvoudig gebruikmaken van de handvatten die de Reference Policy biedt, waardoor deze modules kort en overzichtelijk blijven. Bovendien wordt voorkomen dat bepaalde stukken in meerdere applicatiespecifieke policies moeten worden gedefinieerd.
Doordat SE Linux weinig tot geen invloed heeft op de bestaande onderdelen van de kernel en de reeds ingeladen modules, kan het activeren van nieuwe modules gebeuren zonder dat een herstart van het systeem noodzakelijk is. Slechts bij de eerste activering en bij zeer grote wijzigingen is het opnieuw opstarten van het systeem noodzakelijk.
De grote kracht van SE Linux is het gecontroleerd toegang kunnen geven tot resources. Hierbij kan een resource zowel data zijn, een stuk hardware of een andere applicatie op het systeem. Het eerder genoemde voorbeeld van privilege escalation op een webserver is niet mogelijk als er gebruik wordt gemaakt van SE Linux. De Security Server zal afdwingen dat Apache binnen zijn eigen context moet blijven, ook al is de applicatie zelf kwetsbaar voor een vulnerability. Naar schatting kan iets meer dan de helft van alle in 2007 door Cert gerapporteerde en van buitenaf te misbruiken lekken in daemons met SE Linux worden geminimaliseerd .
SE Linux kan volledig achteraf worden geïnstalleerd en geconfigureerd. Het schrijven van een policy voor een applicatie begint met het analyseren van de behoeften van onder meer de benodigde resources en netwerktoegang van de applicatie. Aan de hand hiervan kan een basispolicy voor de applicatie worden geschreven, die het uitgangspunt voor de uiteindelijke policy vormt. Hiermee is SE Linux geen extra last voor de ontwikkelaar van de applicatie en is het mogelijk de policy na het ontwikkelen van de applicatie te schrijven.
Wel vereist SE Linux diepgaande kennis van zowel de applicatie als het systeem zelf. Een policyschrijver moet het gedrag van de applicatie, inclusief systemcalls, kunnen verklaren.
Doordat SE Linux weinig tot geen invloed heeft op de bestaande onderdelen van de kernel en de reeds ingeladen modules, kan het activeren van nieuwe modules gebeuren zonder dat een herstart van het systeem noodzakelijk is. Slechts bij de eerste activering en bij zeer grote wijzigingen is het opnieuw opstarten van het systeem noodzakelijk.
De grote kracht van SE Linux is het gecontroleerd toegang kunnen geven tot resources. Hierbij kan een resource zowel data zijn, een stuk hardware of een andere applicatie op het systeem. Het eerder genoemde voorbeeld van privilege escalation op een webserver is niet mogelijk als er gebruik wordt gemaakt van SE Linux. De Security Server zal afdwingen dat Apache binnen zijn eigen context moet blijven, ook al is de applicatie zelf kwetsbaar voor een vulnerability. Naar schatting kan iets meer dan de helft van alle in 2007 door Cert gerapporteerde en van buitenaf te misbruiken lekken in daemons met SE Linux worden geminimaliseerd .
SE Linux kan volledig achteraf worden geïnstalleerd en geconfigureerd. Het schrijven van een policy voor een applicatie begint met het analyseren van de behoeften van onder meer de benodigde resources en netwerktoegang van de applicatie. Aan de hand hiervan kan een basispolicy voor de applicatie worden geschreven, die het uitgangspunt voor de uiteindelijke policy vormt. Hiermee is SE Linux geen extra last voor de ontwikkelaar van de applicatie en is het mogelijk de policy na het ontwikkelen van de applicatie te schrijven.
Wel vereist SE Linux diepgaande kennis van zowel de applicatie als het systeem zelf. Een policyschrijver moet het gedrag van de applicatie, inclusief systemcalls, kunnen verklaren.
Volgende pagina (Conclusie - 6/6)