Nyligen tillkännagav författaren till Cosmopolitan C-standardbiblioteket och Redbean-plattformen implementeringen av isoleringsmekanismen pledge() för Linux.
Ursprungligen utvecklat av OpenBSD-projektet , låter pledge dig selektivt förbjuda applikationer från att komma åt oanvända systemanrop (skapa en vitlista över systemanrop för applikationen och förbjuda andra anrop). Till skillnad från åtkomstkontrollmekanismer för syscall som finns i Linux, såsom seccomp, är pledge utformat från grunden för att vara så användarvänligt som möjligt.
Det misslyckade initiativet att isolera applikationer i OpenBSD-basmiljön med hjälp av systrace-mekanismen visade att isolering på nivån för individuella systemanrop är för komplicerat och tidskrävande.
Alternativt föreslogs pledge, vilket möjliggjorde skapandet av isoleringsregler utan att gå in på detaljer och manipulera förberedda åtkomstklasser.
Till exempel, klasser som erbjuds är stdio (ingång/utgång), rpath (skrivskyddade filer), wpath (skrivfiler), cpath (skapa filer), tmppath (arbeta med temporära filer), inet (sockets nätverk), unix (unix sockets ), dns (DNS-upplösning), getpw (läsåtkomst till användardatabas), ioctl (ioctl-anrop), proc (processkontroll), exec (startprocesser) och id (behörighetskontroll).
Reglerna för att arbeta med systemanrop specificeras i form av anteckningar som inkluderar en lista över tillåtna systemanropsklasser och en matris med filsökvägar där åtkomst är tillåten. Efter att ha kompilerat och kört den modifierade applikationen tar kärnan över uppgiften att övervaka efterlevnaden av de angivna reglerna.
Separat utvecklas pledge-implementeringen för FreeBSD, som kännetecknas av möjligheten att isolera applikationer utan att göra ändringar i deras kod, medan i OpenBSD pledge-anropet syftar till tät integration med basmiljön och tillägg av annoteringar till koden av var och en.
Pledge är som den förbjudna frukten vi alla eftertraktar när chefen säger att vi ska använda saker som Linux. Varför spelar det någon roll? Det beror på att panten() faktiskt gör säkerheten begriplig. Linux har aldrig riktigt haft ett lager av säkerhet som bara dödliga kan förstå.
Utvecklarna av Linux pledge-porten följde FreeBSDs exempel och, istället för att göra kodändringar, förberedde de ett ytterligare verktyg från pledge.com som låter dig tillämpa begränsningar utan att ändra din applikationskod. Till exempel, för att köra curl-verktyget med åtkomst endast till systemanropsklasserna stdio, rpath, inet och threadstdio, kör helt enkelt `./pledge.com -p 'stdio rpath inet thread' curl http://example.com`.
Verktyget fungerar på alla Linuxdistributioner från RHEL6 och framåt och kräver inte root-åtkomst. Dessutom, baserat på Cosmopolitan-biblioteket, tillhandahålls ett API för att hantera begränsningar i C-programkod, vilket bland annat möjliggör skapandet av enklaver för att selektivt begränsa åtkomst till specifika applikationsfunktioner.
Det har varit några utvecklare tidigare som har provat detta. Jag tänker inte nämna några namn, eftersom de flesta av dessa projekt aldrig slutfördes. När det gäller SECOMP förklarar onlinehandledningar bara hur man vitlistar systemanrop, så de flesta tappar intresset innan de kommer på hur man filtrerar argument. De projekt som gick framåt hade också förbiseenden som att tillåta setuid/setgid/sticky bitar att ändras. Därför bör inget av de nuvarande alternativen användas. Jag tror att denna ansträngning för oss mycket närmare att ha pledge() än någonsin tidigare.
Implementering kräver inga kärnändringar: verktygsbegränsningar översätts till SECCOMP BPF-regler och bearbetas med hjälp av Linuxs inbyggda systemanropsisoleringsmekanism. Till exempel, om du anropar lov("stdio rpath", 0) konverteras det till ett BPF-filter
Slutligen, om du är intresserad av att lära dig mer, kan du hitta detaljerna på följande länk.