Nylig annonserte forfatteren av Cosmopolitan C-standardbiblioteket og Redbean-plattformen implementeringen av pledge()-isoleringsmekanismen for Linux.
Pledge, som opprinnelig ble utviklet av OpenBSD-prosjektet , lar deg selektivt forhindre at applikasjoner får tilgang til ubrukte systemkall (opprette en hviteliste over systemkall for applikasjonen og forhindre andre kall). I motsetning til tilgangskontrollmekanismer for syscall som er tilgjengelige i Linux, som for eksempel seccomp, er pledge designet fra grunnen av for å være så brukervennlig som mulig.
Det mislykkede initiativet for å isolere applikasjoner i OpenBSD-basemiljøet ved å bruke systrace-mekanismen viste at isolering på nivået til individuelle systemanrop er for komplisert og tidkrevende.
Alternativt ble det foreslått pledge, som tillot å lage isolasjonsregler uten å gå i detaljer og manipulere forberedte tilgangsklasser.
For eksempel er klasser som tilbys stdio (input/output), rpath (skrivebeskyttede filer), wpath (skrive filer), cpath (opprett filer), tmppath (arbeid med midlertidige filer), inet (sockets-nettverk), unix (unix-sockets). ), dns (DNS-oppløsning), getpw (lesetilgang til brukerdatabase), ioctl (ioctl-kall), proc (prosesskontroll), exec (oppstartsprosesser) og id (tillatelseskontroll).
Reglene for arbeid med systemkall er spesifisert i form av merknader som inkluderer en liste over tillatte systemkallklasser og en rekke filstier der tilgang er tillatt. Etter at den modifiserte applikasjonen er kompilert og kjørt, overtar kjernen oppgaven med å overvåke samsvar med de spesifiserte reglene.
Separat utvikles pantsettelsesimplementeringen for FreeBSD, som utmerker seg ved muligheten til å isolere applikasjoner uten å gjøre endringer i koden deres, mens i OpenBSD er pantsettelsessamtalen rettet mot tett integrasjon med basismiljøet og tillegg av merknader til koden av hver enkelt.
Pant er som den forbudte frukten vi alle begjærer når sjefen sier at vi bør bruke ting som Linux. Hvorfor betyr det noe? Det er fordi pantet() faktisk gjør sikkerheten forståelig. Linux har egentlig aldri hatt et lag med sikkerhet som bare dødelige kan forstå.
Utviklerne av Linux pledge-porten fulgte FreeBSDs eksempel , og i stedet for å gjøre kodeendringer, utarbeidet de et ekstra verktøy fra pledge.com som lar deg legge til restriksjoner uten å endre applikasjonskoden din. For eksempel, for å kjøre curl-verktøyet med tilgang kun til systemkallklassene stdio, rpath, inet og threadstdio, kjører du ganske enkelt `./pledge.com -p 'stdio rpath inet thread' curl http://example.com`.
Verktøyet fungerer på alle Linux-distribusjoner fra RHEL6 og utover og krever ikke root-tilgang. I tillegg, basert på Cosmopolitan-biblioteket, tilbys et API for å administrere restriksjoner i C-programkode, noe som blant annet tillater opprettelse av enklaver for selektivt å begrense tilgang til spesifikke applikasjonsfunksjoner.
Det har vært noen få utviklere tidligere som har prøvd dette. Jeg skal ikke nevne navn, for de fleste av disse prosjektene ble aldri fullført. Når det gjelder SECOMP, forklarer nettbaserte opplæringsprogrammer bare hvordan man godkjenner systemanrop, så de fleste mister interessen før de finner ut hvordan man filtrerer argumenter. Prosjektene som gikk videre hadde også forglemmelser som å tillate setuid/setgid/sticky bits å bli endret. Derfor bør ingen av dagens alternativer benyttes. Jeg tror denne innsatsen bringer oss mye nærmere å ha løfte() enn noen gang før.
Implementering krever ingen kjerneendringer: verktøybegrensninger oversettes til SECCOMP BPF-regler og behandles ved hjelp av Linuxs opprinnelige systemanropsisolasjonsmekanisme. For eksempel vil kalle løfte("stdio rpath", 0) konvertere til et BPF-filter
Til slutt, hvis du er interessert i å lære mer, kan du finne detaljene på følgende lenke.