Säkerhetsförbättrad Linux - Security-Enhanced Linux

Säkerhetsförbättrad Linux
SELinux logo.svg
SELinux admin.png
SELinux administratörsgränssnitt i Fedora 8
Ursprungliga författare NSA och Red Hat
Utvecklare röd hatt
Initial release 22 december 2000 ; 20 år sedan ( 2000-12-22 )
Stabil frisättning
3.2 / 4 mars 2021 ; 5 månader sedan ( 2021-03-04 )
Förvar Redigera detta på Wikidata
Skrivet i C
Operativ system Linux
Typ Säkerhet, Linux Security Modules (LSM)
Licens GNU GPL
Hemsida selinuxproject .org , https://www.nsa.gov/what-we-do/research/selinux/

Security-Enhanced Linux ( SELinux ) är en Linux- kärnsäkerhetsmodul som tillhandahåller en mekanism för att stödja säkerhetspolicyer för åtkomstkontroll , inklusive obligatoriska åtkomstkontroller (MAC).

SELinux är en uppsättning kärnmodifieringar och användarutrymmeverktyg som har lagts till i olika Linux-distributioner . Dess arkitektur strävar efter att separera verkställigheten av säkerhetsbeslut från säkerhetspolicyn och effektiviserar mängden programvara som är involverad i säkerhetspolicy. De nyckelbegrepp som ligger till grund för SELinux kan spåras till flera tidigare projekt av United States National Security Agency (NSA).

Översikt

NSA Säkerhetsförbättrat Linux-team beskriver NSA SELinux som

en uppsättning patchar till Linux -kärnan och verktyg för att ge en stark, flexibel, obligatorisk åtkomstkontroll (MAC) -arkitektur till kärnans större delsystem. Det ger en förbättrad mekanism för att genomdriva separationen av information baserad på sekretess- och integritetskrav, vilket gör det möjligt att hantera hot om manipulering och kringgå applikationssäkerhetsmekanismer och möjliggör begränsning av skador som kan orsakas av skadliga eller bristfälliga applikationer. Den innehåller en uppsättning exempel på konfigurationsfiler för säkerhetspolicyer som är utformade för att uppfylla vanliga, allmänna säkerhetsmål.

En Linux -kärna som integrerar SELinux tillämpar obligatoriska åtkomstkontrollpolicyer som begränsar användarprogram och systemtjänster, samt tillgång till filer och nätverksresurser. Att begränsa privilegiet till det minimum som krävs för att arbeta minskar eller eliminerar möjligheten för dessa program och demoner att orsaka skada om de är felaktiga eller äventyras (till exempel via buffertflöden eller felkonfigurationer). Denna inneslutningsmekanism fungerar oberoende av de traditionella Linux ( diskretionära ) åtkomstkontrollmekanismerna. Den har inget begrepp om en "root" -användare och delar inte de välkända bristerna i de traditionella Linux-säkerhetsmekanismerna, till exempel beroende av setuid / setgid- binärer.

Säkerheten för ett "omodifierat" Linux -system (ett system utan SELinux) beror på korrektheten hos kärnan, alla privilegierade applikationer och var och en av deras konfigurationer. Ett fel i något av dessa områden kan tillåta kompromisser i hela systemet. Däremot beror säkerheten på ett "modifierat" system (baserat på en SELinux-kärna) i första hand på kärnans korrekthet och dess säkerhetspolicy-konfiguration. Även om problem med riktighet eller konfiguration av applikationer kan tillåta en begränsad kompromiss mellan enskilda användarprogram och systemdemoner, utgör de inte nödvändigtvis ett hot mot säkerheten för andra användarprogram och systemdemoner eller för säkerheten i systemet som helhet.

Ur ett puristiskt perspektiv tillhandahåller SELinux en hybrid av koncept och funktioner som hämtas från obligatoriska åtkomstkontroller, obligatoriska integritetskontroller , rollbaserad åtkomstkontroll (RBAC) och typhanteringsarkitektur . Tredjepartsverktyg gör det möjligt för en att bygga en mängd olika säkerhetspolicyer.

Historia

Det tidigaste arbetet med att standardisera ett tillvägagångssätt som tillhandahåller obligatoriska och diskretionära åtkomstkontroller (MAC och DAC) inom en UNIX (närmare bestämt POSIX) datormiljö kan hänföras till National Security Agency 's Trusted UNIX (TRUSIX) arbetsgrupp, som träffade från 1987 till 1991 och publicerade en Rainbow Book (#020A), och producerade en formell modell och tillhörande utvärderingsbevisprototyp (#020B) som slutligen inte publicerades.

SELinux utformades för att visa värdet av obligatoriska åtkomstkontroller för Linux -gemenskapen och hur sådana kontroller kan läggas till Linux. Ursprungligen måste de patchar som utgör SELinux uttryckligen tillämpas på Linux -kärnkällan; SELinux slogs samman till Linux -kärnans huvudlinje i Linux -kärnans 2.6 -serie.

NSA, den ursprungliga primära utvecklaren av SELinux, släppte den första versionen till utvecklingsgemenskapen med öppen källkod under GNU GPL den 22 december 2000. Programvaran slogs samman till mainline Linux-kärnan 2.6.0-test3, släpptes den 8 augusti 2003 Andra viktiga bidragsgivare inkluderar Red Hat , Network Associates , Secure Computing Corporation , Tresys Technology och Trusted Computer Solutions. Experimentella portar för FLASK /TE -implementeringen har gjorts tillgängliga via TrustedBSD -projektet för operativsystemen FreeBSD och Darwin .

Säkerhetsförbättrad Linux implementerar Flux Advanced Security Kernel (FLASK). En sådan kärna innehåller arkitektoniska komponenter prototyperade i Fluke -operativsystemet . Dessa ger generellt stöd för att genomdriva många typer av obligatoriska åtkomstkontrollpolicyer, inklusive de som baseras på begreppen typhantering , rollbaserad åtkomstkontroll och säkerhet på flera nivåer . FLASK var i sin tur baserat på DTOS, ett Mach-härledt distribuerat betrodt operativsystem , samt Trusted Mach, ett forskningsprojekt från Trusted Information Systems som hade inflytande på design och implementering av DTOS.

Användare, policyer och säkerhetssammanhang

SELinux -användare och roller behöver inte vara relaterade till de faktiska systemanvändarna och rollerna. För varje nuvarande användare eller process tilldelar SELinux en kontext med tre strängar som består av ett användarnamn, roll och domän (eller typ). Detta system är mer flexibelt än normalt: vanligtvis delar de flesta riktiga användare samma SELinux -användarnamn och all åtkomstkontroll hanteras via den tredje taggen, domänen. Omständigheterna under vilka en process tillåts till en viss domän måste konfigureras i policyn. Kommandot runcontillåter start av en process i ett uttryckligen specificerat sammanhang (användare, roll och domän), men SELinux kan neka övergången om den inte godkänns av policyn.

Filer, nätverksportar och annan maskinvara har också ett SELinux -sammanhang, som består av ett namn, roll (används sällan) och typ. När det gäller filsystem kallas mappning mellan filer och säkerhetskontexterna för märkning. Märkningen definieras i policyfiler men kan också justeras manuellt utan att ändra policyn. Hårdvarutyper är till exempel ganska detaljerade bin_t(alla filer i mappen /facket) eller postgresql_port_t(PostgreSQL -port, 5432). SELinux -sammanhanget för ett fjärrfilsystem kan anges specifikt vid monteringstid.

SELinux lägger till -Zomkopplaren till skalkommandona ls, psoch några andra, så att filernas eller processens säkerhetskontext kan ses.

Typiska policyregler består av uttryckliga behörigheter, till exempel vilka domäner användaren måste ha för att utföra vissa åtgärder med det angivna målet (läs, kör eller i fallet med nätverksport, bind eller anslut) och så vidare. Mer komplexa mappningar är också möjliga, med roller och säkerhetsnivåer.

En typisk policy består av en mappningsfil (märkning), en regelfil och en gränssnittsfil som definierar domänövergången. Dessa tre filer måste sammanställas tillsammans med SELinux -verktygen för att skapa en enda policyfil. Den resulterande policyfilen kan laddas in i kärnan för att göra den aktiv. Laddnings- och lossningspolicyer kräver ingen omstart. Policyfilerna är antingen handskrivna eller kan genereras från det mer användarvänliga SELinux -hanteringsverktyget. De testas normalt i tillåtande läge först, där överträdelser loggas men tillåts. Den audit2allowVerktyget kan användas senare för att producera ytterligare regler som sträcker sig policyn så att alla legitima verksamheter ansökan är begränsat.

Funktioner

SELinux -funktioner inkluderar:

  • Ren åtskillnad mellan policy och efterlevnad
  • Väldefinierade policygränssnitt
  • Stöd för applikationer som frågar efter policyn och tillämpar åtkomstkontroll (till exempel jobb som kör kör i rätt sammanhang)
  • Oberoende av specifik politik och policyspråk
  • Oberoende av specifika säkerhetsetikettformat och innehåll
  • Individuella etiketter och kontroller för kärnobjekt och tjänster
  • Stöd för policyändringar
  • Separata åtgärder för att skydda systemintegritet (domän typ) och datasekretess ( säkerhet på flera nivåer )
  • Flexibel policy
  • Kontroller över processinitialisering och arv och programkörning
  • Kontroller över filsystem, kataloger, filer och öppna filbeskrivare
  • Kontroller över uttag, meddelanden och nätverksgränssnitt
  • Kontroller över användningen av "funktioner"
  • Cachad information om åtkomstbeslut via Access Vector Cache (AVC)
  • Standardpolicy (allt som inte uttryckligen anges i policyn är inte tillåtet)

Implementeringar

SELinux har implementerats i Android sedan version 4.3.

Bland gratis community-stödda Linux-distributioner var Fedora en av de tidigaste adoptörerna, inklusive stöd för det som standard sedan Fedora Core 2. Andra distributioner inkluderar stöd för det som Debian från version 9 Stretch release och Ubuntu från och med 8.04 Hardy Heron. Från och med version 11.1 innehåller openSUSE SELinux "basic enablement". SUSE Linux Enterprise 11 har SELinux som en "teknikförhandsgranskning".

SELinux är populärt i system baserade på Linux -behållare , som CoreOS Container Linux och rkt. Det är användbart som en ytterligare säkerhetskontroll för att ytterligare genomdriva isolering mellan distribuerade containrar och deras värd.

SELinux är tillgängligt sedan 2005 som en del av Red Hat Enterprise Linux (RHEL) version 4 och alla framtida versioner. Denna närvaro återspeglas också i motsvarande versioner av CentOS och Scientific Linux . Den policy som stöds i RHEL4 är riktad politik som syftar till maximal användarvänlighet och är därför inte så restriktiv som den kan vara. Framtida versioner av RHEL är planerade att ha fler mål i den riktade politiken, vilket kommer att innebära mer restriktiva policyer.

Använd scenarier

SELinux kan eventuellt styra vilka aktiviteter ett system tillåter varje användare, process och demon, med mycket exakta specifikationer. Det används för att begränsa demoner som databasmotorer eller webbservrar som har klart definierade datatillgångar och aktivitetsrättigheter. Detta begränsar potentiell skada från en begränsad demon som blir äventyrad.

Kommandoradsverktyg inkluderar: chcon, restorecon, restorecond, runcon, secon, fixfiles, setfiles, load_policy, booleans, getsebool, setsebool, togglesebool setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabled, ochselinux-policy-upgrade

Exempel

Så här sätter du SELinux i verkställande läge:

$ sudo setenforce 1

För att fråga efter SELinux -status:

$ getenforce

Jämförelse med AppArmor

SELinux representerar en av flera möjliga metoder för att begränsa de åtgärder som installerad programvara kan vidta. Ett annat populärt alternativ kallas AppArmor och är tillgängligt på SUSE Linux Enterprise Server (SLES), openSUSE och Debian-baserade plattformar. AppArmor utvecklades som en komponent till den nu nedlagda Immunix Linux- plattformen. Eftersom AppArmor och SELinux skiljer sig radikalt från varandra, bildar de tydliga alternativ för programvarukontroll. Medan SELinux återuppfinner vissa begrepp för att ge tillgång till en mer uttrycksfull uppsättning policyval, var AppArmor utformat för att vara enkelt genom att utöka samma administrativa semantik som används för DAC upp till den obligatoriska åtkomstkontrollnivån.

Det finns flera viktiga skillnader:

  • En viktig skillnad är att AppArmor identifierar filsystemobjekt med sökvägsnamn istället för inode. Detta innebär att till exempel en fil som är otillgänglig kan bli tillgänglig under AppArmor när en hård länk skapas till den, medan SELinux skulle neka åtkomst via den nyskapade hårda länken.
    • Som ett resultat kan AppArmor sägas inte vara ett typhanteringssystem , eftersom filer inte tilldelas en typ; i stället refereras de bara till i en konfigurationsfil.
  • SELinux och AppArmor skiljer sig också väsentligt åt i hur de administreras och hur de integreras i systemet.
  • Eftersom det strävar efter att återskapa traditionella DAC-kontroller med tillämpning på MAC-nivå, är AppArmors uppsättning operationer också betydligt mindre än de som finns tillgängliga under de flesta SELinux-implementeringar. Till exempel består AppArmors uppsättning operationer av: läs, skriv, lägg till, kör, lås och länk. De flesta SELinux -implementeringar kommer att stödja antalet operativa storleksordningar mer än så. Till exempel stöder SELinux vanligtvis samma behörigheter, men innehåller också kontroller för mknod, bindning till nätverksuttag, implicit användning av POSIX -funktioner, laddning och lossning av kärnmoduler, olika sätt att få tillgång till delat minne, etc.
  • Det finns inga kontroller i AppArmor för kategoriskt begränsande POSIX -funktioner. Eftersom den nuvarande implementeringen av funktioner inte innehåller något begrepp om ett ämne för operationen (endast aktören och operationen) är det vanligtvis MAC -lagrets jobb att förhindra privilegierade operationer på filer utanför aktörens tvingade kontrollområde (dvs "Sandbox" ). AppArmor kan förhindra att dess egen policy ändras och förhindra att filsystem monteras/avmonteras, men gör inget för att hindra användare från att gå utanför sina godkända kontrollområden.
    • Till exempel kan det anses fördelaktigt för helpdeskanställda att byta äganderätt eller behörighet för vissa filer även om de inte äger dem (till exempel på en avdelningsfilresurs). Administratören vill inte ge användaren (er) rootåtkomst i rutan så att de ger dem CAP_FOWNEReller CAP_DAC_OVERRIDE. Under SELinux kan administratören (eller plattformsleverantören) konfigurera SELinux för att neka alla funktioner till annars okonfinierade användare och sedan skapa begränsade domäner för den anställda att kunna övergå till efter inloggning, en som kan utöva dessa funktioner, men bara på filer med lämplig typ.
  • Det finns ingen uppfattning om säkerhetsnivå på flera nivåer med AppArmor, så det finns ingen hård BLP- eller Biba -verkställighet tillgänglig.
  • AppArmor -konfigurationen görs med endast vanliga plattfiler. SELinux (som standard i de flesta implementeringar) använder en kombination av platta filer (används av administratörer och utvecklare för att skriva mänsklig läsbar policy innan den sammanställs) och utökade attribut.
  • SELinux stöder konceptet med en "remote policy server" (konfigurerbar via /etc/selinux/semanage.conf) som en alternativ källa för policykonfiguration. Central hantering av AppArmor är vanligtvis komplicerat avsevärt eftersom administratörer måste välja mellan konfigurationsdistributionsverktyg som körs som root (för att tillåta policyuppdateringar) eller konfigureras manuellt på varje server.

Liknande system

Se även: Samsung Knox

Isolering av processer kan också åstadkommas genom mekanismer som virtualisering ; i OLPC -projektet, till exempel, i sin första genomförandet sandboxed enskilda program i lätta Vservers . Även NSA har antagit några av de SELinux begrepp i utökad säkerhet Android .

General Dynamics bygger och distribuerar PitBull Trusted Operating System, en förbättring på flera nivåer (MLS) för Red Hat Enterprise Linux .

Se även

Referenser

externa länkar