Boken "BPF för övervakning av Linux"

Hej, Habrörjare! Virtuell BPF-maskin är en av de viktigaste komponenterna i Linux-kärnan. En korrekt användning av den kommer att hjälpa systemtekniker att identifiera fel och lösa även de mest komplexa problemen. Du kommer att lära dig att skapa program som spårar och modifierar kärnans beteende, säkert införa kod för att övervaka händelser i kärnan och mycket mer. David Calavera och Lorenzo Fontana hjälper dig att utforska BPF:s möjligheter. Utöka dina kunskaper om prestandaoptimering, nätverk och säkerhet. — Använd BPF för att spåra och modifiera Linux-kärnans beteende. — Införa kod för säker övervakning av händelser i kärnan — utan att behöva kompilera om kärnan eller starta om systemet. — Använd praktiska kodexempel i C, Go eller Python. — Hantera situationen genom att behärska livscykeln för BPF-programmet.

Linux-kärnans säkerhet, dess möjligheter och Seccomp

BPF erbjuder ett kraftfullt sätt att utöka kärnan utan att äventyra stabilitet, säkerhet och hastighet. Av denna anledning tyckte kärnutvecklarna att det skulle vara bra att utnyttja dess mångsidighet för att förbättra processisolationen i Seccomp genom att implementera Seccomp-filter som stöds av BPF-program, även kända som Seccomp BPF. I detta kapitel kommer vi att förklara vad Seccomp är och hur det tillämpas. Därefter får du veta hur man skriver Seccomp-filter med hjälp av BPF-program. Vi kommer också att titta på inbyggda BPF-händelser som finns i kärnan för Linux-säkerhetsmoduler.

Linux säkerhetsmoduler (LSM) är en plattform som erbjuder en uppsättning funktioner som kan tillämpas för en standardiserad implementering av olika säkerhetsmodeller. LSM kan användas direkt i kärnans källkodsträd, exempelvis Apparmor, SELinux och Tomoyo.

Låt oss börja med att diskutera Linux möjligheter.

Funktioner

Kärnan av Linux-funktioner ligger i att du behöver ge en icke-privilegierad process tillstånd att utföra en viss uppgift, men utan att använda suid för detta syfte, eller på annat sätt göra processen privilegierad, vilket minskar risken för attacker och ger processen möjlighet att utföra specifika uppgifter. Till exempel, om din applikation behöver öppna en privilegierad port, låt oss säga 80, istället för att köra processen som root kan du helt enkelt ge den möjlighet att använda CAP_NET_BIND_SERVICE.

Låt oss överväga ett Go-program med namnet main.go:

package main
import (
            "net/http"
            "log"
)
func main() {
     log.Fatalf("%v", http.ListenAndServe(":80", nil))
}

Detta program driver en HTTP-server på port 80 (detta är en privilegierad port). Vanligtvis kör vi den direkt efter kompileringen:

$ go build -o capabilities main.go
$ ./capabilities

Men eftersom vi inte ger root-rättigheter kommer denna kod att ge ett fel vid bindning av porten:

2019/04/25 23:17:06 listen tcp :80: bind: permission denied
exit status 1

capsh (skalet för hantering) är ett verktyg som kör ett skal med en specifik uppsättning funktioner.

I det här fallet, som redan nämnts, istället för att ge fullständiga root-rättigheter kan vi tillåta bindning av privilegierade portar genom att ge funktionen cap_net_bind_service tillsammans med alla andra som redan finns i programmet. För detta kan vi omge vårt program med capsh:

# capsh --caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' 
   --keep=1 --user="nobody" 
   --addamb=cap_net_bind_service -- -c "./capabilities"

Låt oss gå igenom detta kommando.

• capsh — vi använder capsh som skal.
• —caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' — eftersom vi behöver byta användare (vi vill inte köra med root-rättigheter), anges cap_net_bind_service och rättigheten att faktiskt ändra användar-ID från root till nobody, det vill säga cap_setuid och cap_setgid.
• —keep=1 — vi vill behålla de inställda funktionerna när vi byter från root-kontot.
• —user="nobody" — den slutgiltiga användaren som kör programmet kommer att vara nobody.
• —addamb=cap_net_bind_service — vi specificerar att rensa de relaterade funktionerna efter att vi har bytt från root-läget.
• — -c "./capabilities" — vi kör helt enkelt programmet.

Relaterade funktioner är en speciell typ av funktioner som ärvs av barnprogram när den nuvarande programmet kör dem med hjälp av execve(). Endast funktioner som har tillåtits som relaterade kan ärvas, eller med andra ord som miljöfunktioner.

Du kanske undrar vad +eip betyder efter att möjligheten angivits i alternativet —caps. Dessa flaggor används för att definiera att möjligheten:

-måste aktiveras (p);

-är tillgänglig för användning (e);

-kan ärvas av underprocesser (i).

Eftersom vi vill använda cap_net_bind_service, måste vi göra detta med flaggan e. Därefter kör vi en shell i kommandot. Som ett resultat kommer binärfilen capabilities att startas och vi måste märka den med flaggan i. Slutligen vill vi att möjligheten ska aktiveras (det gjorde vi utan att ändra UID) med hjälp av p. Det ser ut som cap_net_bind_service+eip.

Du kan kontrollera resultatet med hjälp av ss. Vi kommer att förkorta utdata något så att den får plats på sidan, men den kommer att visa den relaterade porten och användar-ID:t, som inte är 0, i detta fall 65 534:

# ss -tulpn -e -H | cut -d' ' -f17-
128 *:80 *:*
users:(("capabilities",pid=30040,fd=3)) uid:65534 ino:11311579 sk:2c v6only:0

I detta exempel använde vi capsh, men du kan skriva en shell med hjälp av libcap. För mer information, se man 3 libcap.

När en utvecklare skriver program vet han ofta inte i förväg alla möjligheter som programmet behöver under körning; dessutom kan dessa möjligheter ändras i nya versioner.

För att bättre förstå möjligheterna i vårt program kan vi använda verktyget BCC capable, som sätter kprobe för kärnfunktionen cap_capable:

/usr/share/bcc/tools/capable
TIME      UID  PID   TID   COMM               CAP    NAME           AUDIT
10:12:53 0 424     424     systemd-udevd 12 CAP_NET_ADMIN         1
10:12:57 0 1103   1101   timesync        25 CAP_SYS_TIME         1
10:12:57 0 19545 19545 capabilities       10 CAP_NET_BIND_SERVICE 1

Vi kan uppnå samma sak genom att använda bpftrace med en enraders kprobe i kärnfunktionen cap_capable:

bpftrace -e 
   'kprobe:cap_capable {
      time("%H:%M:%S ");
      printf("%-6d %-6d %-16s %-4d %dn", uid, pid, comm, arg2, arg3);
    }' 
    | grep -i capabilities

Detta kommer att ge något i stil med följande, om möjligheterna i vårt program har aktiverats efter kprobe:

12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 10 1

Den femte kolumnen representerar de möjligheter som processen behöver, och eftersom dessa utdata inkluderar icke-auditloggade händelser, ser vi alla icke-auditkontroller och slutligen den erforderliga möjligheten med auditflaggan (den sista i utdata) inställd på 1. Den möjlighet som intresserar oss är CAP_NET_BIND_SERVICE, som definieras som en konstant i kärnans källkod i filen include/uapi/linux/ability.h med identifieraren 10:

/* Allows binding to TCP/UDP sockets below 1024 */
/* Allows binding to ATM VCIs below 32 */
#define CAP_NET_BIND_SERVICE 10<source lang="go">

Möjligheterna används ofta under körning av containrar, som runC eller Docker, för att de ska fungera i ett icke-privilegerat läge, men de får endast de möjligheter som krävs för att köra de flesta applikationer. När en applikation kräver specifika möjligheter kan de tillhandahållas i Docker med hjälp av —cap-add:

docker run -it --rm --cap-add=NET_ADMIN ubuntu ip link add dummy0 type dummy

Detta kommando kommer att ge containern möjligheten CAP_NET_ADMIN, vilket gör att den kan konfigurera nätverkskopplingen för att lägga till gränssnittet dummy0.

I nästa avsnitt visas användningen av sådana möjligheter, som filtrering, men med en annan metod som låter oss programmera våra egna filter.

Seccomp

Seccomp står för Secure Computing, det är en säkerhetsnivå som implementeras i Linux-kärnan och låter utvecklare filtrera specifika systemanrop. Även om Seccomp är jämförbart med Linux-möjligheter, gör dess förmåga att hantera specifika systemanrop det mycket mer flexibelt i jämförelse med dem.

Seccomp och Linux-möjligheter utesluter inte varandra, de används ofta tillsammans för att dra nytta av båda tillvägagångssätten. Till exempel kan du vilja ge en process möjligheten CAP_NET_ADMIN, men inte tillåta den att ta emot anslutningar via socket genom att blockera systemanropen accept och accept4.

Filtreringsmetoden för Seccomp är baserad på BPF-filter som fungerar i SECCOMP_MODE_FILTER-läge, och filtreringssystemanropen utförs på samma sätt som för paket.

Seccomp-filter laddas med hjälp av prctl genom operationen PR_SET_SECCOMP. Dessa filter har formen av ett BPF-program som körs för varje Seccomp-paket, som tillhandahålls med hjälp av strukturen seccomp_data. Denna struktur innehåller referensarkitektur, en pekare till instruktionerna för processorn under systemanropet och högst sex argument för systemanropet, uttryckt som uint64.

Så här ser strukturen seccomp_data ut från källkoden i filen linux/seccomp.h:

struct seccomp_data {
int nr;
      __u32 arch;
      __u64 instruction_pointer;
      __u64 args[6];
};

Som framgår av denna struktur kan vi filtrera baserat på systemanropet, dess argument eller deras kombination.

Efter att varje Seccomp-filterpaket har mottagits måste det genomföra en bearbetning för att fatta ett slutligt beslut och meddela kärnan vad som ska göras härnäst. Det slutliga beslutet uttrycks med en av de returnerade värdena (statuskoder).

— SECCOMP_RET_KILL_PROCESS — avslutning av hela processen omedelbart efter filtrering av systemanropet, vilket inte genomförs på grund av detta.

— SECCOMP_RET_KILL_THREAD — avslutning av den aktuella tråden omedelbart efter filtrering av systemanropet, vilket inte genomförs på grund av detta.

— SECCOMP_RET_KILL — alias för SECCOMP_RET_KILL_THREAD, kvarlämnat för bakåtkompatibilitet.

— SECCOMP_RET_TRAP — systemanropet är förbjudet, och signalen SIGSYS (Bad System Call) skickas till den anropande uppgiften.

— SECCOMP_RET_ERRNO — systemanropet genomförs inte, och en del av det returnerade värdet från filtret SECCOMP_RET_DATA överförs till användarrummet som värdet av errno. Beroende på felets orsak returneras olika errno-värden. Listan över felnummer finns i nästa avsnitt.

— SECCOMP_RET_TRACE — används för att informera spåraren ptrace med hjälp av — PTRACE_O_TRACESECCOMP för att fånga upp när ett systemanrop utförs för att se och kontrollera denna process. Om spåraren inte är ansluten returneras ett fel, errno ställs in på -ENOSYS, och systemanropet genomförs inte.

— SECCOMP_RET_LOG — systemanropet är tillåtet och registreras i loggen.

— SECCOMP_RET_ALLOW — systemanropet tillåts helt enkelt.

ptrace är ett systemanrop för att implementera spårningsmekanismer i en process, kallad tracee, med möjlighet att observera och kontrollera körningen av processen. Spårningsprogrammet kan effektivt påverka körningen och ändra registrerna i tracee. I kontexten av Seccomp används ptrace när SECCOMP_RET_TRACE-kod körs, vilket gör att spåraren kan förhindra att systemanropet genomförs och implementera sin egen logik.

Seccomp-fel

Ibland, när du arbetar med Seccomp, kommer du att stöta på olika fel som identifieras av returvärdet av typen SECCOMP_RET_ERRNO. För att rapportera ett fel kommer systemanropet seccomp att returnera -1 istället för 0.

Följande fel kan förekomma:

— EACCESS — den anropande parten har inte behörighet att göra systemanrop. Detta sker vanligtvis på grund av att den saknar CAP_SYS_ADMIN-behörigheter eller att no_new_privs inte har ställts in med hjälp av prctl (vi kommer att diskutera detta senare);

— EFAULT — de angivna parametrarna (args i strukturen seccomp_data) har ingen giltig adress;

— EINVAL — här kan det finnas fyra orsaker:

- den begärda operationen är okänd eller stöds inte av kärnan i den aktuella konfigurationen;

- de angivna flaggorna är ogiltiga för den begärda operationen;

- operationen inkluderar BPF_ABS, men det finns problem med det angivna offsetet som kan överskrida storleken på strukturen seccomp_data;

- antalet instruktioner som skickas till filtret överskrider maximalt tillåten;

— ENOMEM — inte tillräckligt med minne för att köra programmet;

— EOPNOTSUPP — operationen angav att SECCOMP_GET_ACTION_AVAIL åtgärden var tillgänglig, men kärnan stöder inte återvändande i argumenten;

— ESRCH — det uppstod ett problem med att synkronisera en annan tråd;

— ENOSYS — ingen spårningsprogram kopplad till SECCOMP_RET_TRACE åtgärden.

prctl är ett systemanrop som låter program i användarläge hantera (ställa in och hämta) specifika aspekter av processen, såsom byteordning, trådnamn, skyddade beräkningslägen (Seccomp), behörigheter, prestanda händelser osv.

Seccomp kan verka som en sandlådeteknik, men så är det inte. Seccomp är ett verktyg som tillåter användare att utveckla mekanismen för sandlåda. Låt oss nu titta på hur program för användarinteraktion skapas med hjälp av en filter som anropas direkt av systemanropet Seccomp.

Exempel på BPF Seccomp-filter

Här visar vi hur vi kopplar samman de två åtgärderna som diskuterats tidigare, nämligen:

— vi skriver ett Seccomp BPF-program som kommer att tillämpas som en filter med olika returkoder beroende på de beslut som fattas;

— vi laddar upp filtret med hjälp av prctl.

Först behövs rubriker från standardbiblioteket och Linux-kärnan:

#include <errno.h>
#include <linux/audit.h>
#include <linux/bpf.h>
#include <linux/filter.h>
#include <linux/seccomp.h>
#include <linux/unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <unistd.h>

Innan vi försöker köra detta exempel måste vi säkerställa att kärnan är kompilera med CONFIG_SECCOMP och CONFIG_SECCOMP_FILTER satta på y. Detta kan kontrolleras på en arbetsmaskin så här:

cat /proc/config.gz | zcat | grep -i CONFIG_SECCOMP

Den andra delen av koden utgörs av funktionen install_filter, som består av två delar. Den första delen innehåller vår lista med BPF-filterinstruktioner:

static int install_filter(int nr, int arch, int error) {
  struct sock_filter filter[] = {
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, arch))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3),
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, nr))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
  };

Instruktionerna sätts in med makron BPF_STMT och BPF_JUMP, definierade i filen linux/filter.h.
Låt oss gå igenom instruktionerna.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) — systemet laddar och ackumulerar med BPF_LD i form av ett ord BPF_W, paketdata finns på ett fast offset BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) — kontrollerar med BPF_JEQ om värdet av arkitekturen i konstantens ackumulator BPF_K är lika med arch. Om så är fallet, går den vidare med offset 0 till nästa instruktion, annars hoppar den med offset 3 (i detta fall), eftersom arch inte matchar.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) — laddar och ackumulerar med BPF_LD i form av ett ord BPF_W, vilket är nummer på systemanropet som finns på ett fast offset BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — jämför nummer på systemanropet med värdet av variabeln nr. Om de är lika går den vidare till nästa instruktion och förhindrar systemanropet; annars tillåter den systemanropet med SECCOMP_RET_ALLOW.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)) — avslutar programmet med BPF_RET och returnerar ett fel SECCOMP_RET_ERRNO med numret från variabeln err.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) — avslutar programmet med BPF_RET och tillåter exekvering av systemanropet med SECCOMP_RET_ALLOW.

SECCOMP — ÄR CBPF
Kanske undrar du varför en lista med instruktioner används istället för ett ELFO-objekt som kompilerats eller ett C-program som kompilerats med JIT.

Det finns två skäl till detta.

• För det första tillämpar Seccomp cBPF (klassisk BPF) istället för eBPF, vilket innebär: det har inga register utan endast en ackumulator för att lagra det senaste resultatet av beräkningarna, som man kan se i exemplet.

• För det andra tar Seccomp en pekare till en BPF-instruktionsarray direkt och inget mer. De makron vi använde hjälper bara till att specificera dessa instruktioner i ett programmerarvänligt format.

Om du behöver mer hjälp för att förstå denna sammansättning, överväg pseudokoden som gör samma sak:

if (arch != AUDIT_ARCH_X86_64) {
    return SECCOMP_RET_ALLOW;
}
if (nr == __NR_write) {
    return SECCOMP_RET_ERRNO;
}
return SECCOMP_RET_ALLOW;

Efter att ha definierat filterkoden i socket_filter-strukturen måste vi definiera sock_fprog som innehåller koden och den beräknade längden på filtret. Denna datastruktur är nödvändig som argument för att deklarera processens arbete vidare:

struct sock_fprog prog = {
   .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
   .filter = filter,
};

Det finns bara en sak kvar att göra i funktionen install_filter — ladda själva programmet! För detta använder vi prctl, med PR_SET_SECCOMP som alternativ för att gå in i skyddade beräkningslägen. Vi anger sedan läget att ladda filtret med hjälp av SECCOMP_MODE_FILTER, som finns i variabeln prog av typen sock_fprog:

  if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) {
    perror("prctl(PR_SET_SECCOMP)");
    return 1;
}
return 0;
}

Slutligen kan vi dra nytta av vår funktion install_filter, men innan dess måste vi aktivera prctl för att ställa in PR_SET_NO_NEW_PRIVS för den aktuella körningen och på så sätt undvika att barnprocesserna får bredare privilegier än föräldrarna. Under denna process kan vi göra följande prctl-anrop i funktionen install_filter utan root-behörighet.

Nu kan vi kalla funktionen install_filter. Vi blockerar alla systemanrop write relaterade till X86-64-arkitekturen och ger helt enkelt tillåtelse, vilket blockerar alla försök. Efter att filtret har installerats fortsätter vi med att använda den första argumentet:

int main(int argc, char const *argv[]) {
  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
   perror("prctl(NO_NEW_PRIVS)");
   return 1;
  }
   install_filter(__NR_write, AUDIT_ARCH_X86_64, EPERM);
  return system(argv[1]);
}

Låt oss börja. För att kompilera vårt program kan vi använda antingen clang eller gcc; i vilket fall som helst handlar det bara om att kompilera filen main.c utan speciella alternativ:

clang main.c -o filter-write

Som nämnts har vi blockerat alla skrivningar i programmet. För att kontrollera detta behövs ett program som skriver ut något — ls verkar vara en bra kandidat. Så här fungerar det vanligtvis:

ls -la
total 36
drwxr-xr-x 2 fntlnz users 4096 Apr 28 21:09 .
drwxr-xr-x 4 fntlnz users 4096 Apr 26 13:01 ..
-rwxr-xr-x 1 fntlnz users 16800 Apr 28 21:09 filter-write
-rw-r--r-- 1 fntlnz users 19 Apr 28 21:09 .gitignore
-rw-r--r-- 1 fntlnz users 1282 Apr 28 21:08 main.c

Perfekt! Så här ser det ut när vi använder vårt skalprogram: vi skickar helt enkelt programmet vi vill testa som det första argumentet:

.\/filter-write "ls -la"

Efter att ha körts ger detta program helt tom utdata. Vi kan dock använda strace för att se vad som händer:

strace -f .\/filter-write "ls -la"

Resultatet är starkt förkortat, men den relevanta delen visar att skrivningarna blockeras med felet EPERM — det som vi konfigurerade. Det betyder att programmet inte skriver ut något eftersom det inte kan få tillgång till systemanropet write:

[pid 25099] write(2, "ls: ", 4) = -1 EPERM (Åtgärd inte tillåten)
[pid 25099] write(2, "write error", 11) = -1 EPERM (Åtgärd inte tillåten)
[pid 25099] write(2, "n", 1) = -1 EPERM (Åtgärd inte tillåten)

Nu förstår du hur Seccomp BPF fungerar, och du har en bra uppfattning om vad som kan göras med det. Men skulle det inte vara bättre att åstadkomma samma sak med eBPF istället för cBPF för att utnyttja dess hela potential?

När det gäller eBPF-program tänker de flesta att de bara skriver dem och laddar upp dem med administratörsrättigheter. Även om detta påstående oftast är sant, implementerar kärnan en uppsättning mekanismer för att skydda eBPF-objekt på olika nivåer. Dessa mekanismer kallas BPF LSM-traps.

BPF LSM-fällor

För att säkerställa en arkitekturoberoende kontroll av systemhändelser implementerar LSM begreppet fällor. Tekniskt sett är ett fällanrop liknande ett systemanrop, men det är oberoende av systemet och integrerat med infrastrukturen. LSM erbjuder ett nytt koncept där abstraheringsnivån kan hjälpa till att undvika problem som uppstår vid arbete med systemanrop på olika arkitekturer.

Vid tidpunkten för skrivandet av boken hade kärnan sju fällor kopplade till BPF-program, och SELinux är den enda inbyggda LSM som implementerar dem.

Källkoden för fällorna finns i kärnans träd i filen include\/linux\/security.h:

extern int security_bpf(int cmd, union bpf_attr *attr, unsigned int size);
extern int security_bpf_map(struct bpf_map *map, fmode_t fmode);
extern int security_bpf_prog(struct bpf_prog *prog);
extern int security_bpf_map_alloc(struct bpf_map *map);
extern void security_bpf_map_free(struct bpf_map *map);
extern int security_bpf_prog_alloc(struct bpf_prog_aux *aux);
extern void security_bpf_prog_free(struct bpf_prog_aux *aux);

Varje av dem kommer att anropas i olika steg av utförandet:

— security_bpf — genomför en första kontroll av de systemanrop som utförs av BPF;

— security_bpf_map — kontrollerar när kärnan returnerar en filbeskrivare för en karta;

— security_bpf_prog — kontrollerar när kärnan returnerar en filbeskrivare för ett eBPF-program;

— security_bpf_map_alloc — kontrollerar om säkerhetsfältet inuti BPF-kartor är initierat;

— security_bpf_map_free — kontrollerar om säkerhetsfältet inuti BPF-kartor rensas;

— security_bpf_prog_alloc — kontrollerar om säkerhetsfältet inuti BPF-program är initierat;

— security_bpf_prog_free — kontrollerar om säkerhetsfältet inuti BPF-program rensas.

Nu, när vi ser allt detta, förstår vi: Idén med LSM BPF interceptorer är att de kan skydda varje eBPF-objekt genom att säkerställa att endast de som har de nödvändiga privilegierna kan utföra operationer på kartor och program.

Sammanfattning

Säkerhet är inget som du kan implementera universellt för allt du vill skydda. Det är viktigt att kunna skydda system på olika nivåer och på olika sätt. Tro på det eller inte, det bästa sättet att säkra ett system är att organisera olika säkerhetsnivåer från olika positioner så att en nedgradering av säkerheten på en nivå inte tillåter åtkomst till hela systemet. Kärnutvecklarna har gjort ett stort arbete för att ge oss en uppsättning olika lager och kontaktpunkter. Vi hoppas att vi har gett dig en bra förståelse för vad lager är och hur man använder BPF-program för att arbeta med dem.

Om författarna

David Calavera är teknisk direktör på Netlify. Han har arbetat inom support för Docker och varit involverad i utvecklingen av Runc, Go och BCC-verktyg, samt andra öppna källkodsprojekt. Känd för sitt arbete med Docker-projekt och utvecklingen av Docker-plugin-ecosystemet. David älskar flamescanning och strävar alltid efter att optimera prestanda.

Lorenzo Fontana Arbetar i ett team av programvaruutvecklare med öppen källkod på Sysdig, där han främst arbetar med Falco – ett projekt från Cloud Native Computing Foundation som säkerställer säkerhet för containerkörningsmiljöer och upptäckte avvikelser genom kärnmodul och eBPF. Han är passionerad om distribuerade system, programvarudefinierade nätverk, Linux-kärnan och prestandaanalys.

” För mer information om boken kan man läsa på förlagets webbplats
» Innehållsförteckning
» Utdrag

För Habr-följare är det 25 % rabatt med koden — Linux

Vid betalning av den tryckta versionen av boken skickas en e-bok till e-post.

Källa: habr.com