Raamat „BPF Linuxi jälgimiseks“

Tere, Habrikad! Virtuaalne masin BPF on üks tähtsamaid komponente Linuxi tuumas. Selle nõuetekohane rakendamine võimaldab süsteemiinseneridel leida vigu ja lahendada isegi kõige keerulisemaid probleeme. Te õpite looma programme, mis jälgivad ja muudavad tuuma käitumist, saate ohutult sisestada koodi sündmuste jälgimiseks tuumas ja palju muud. David Calavera ja Lorenzo Fontana aitavad teil avada BPF võimalused. Täiendage oma teadmisi jõudluse optimeerimise, võrkude ja turvalisuse kohta. — Kasutage BPF-d Linuxi tuuma käitumise jälgimiseks ja muutmiseks. — Sisestage kood ohutuks sündmuste jälgimiseks tuumas — ilma tuuma uuesti kompileerimata või süsteemi taaskäivitamata. — Kasutage mugavaid koodinäiteid C, Go või Pythonis. — Hallake olukorda, valdades BPF programmi elutsüklit.

Linuxi tuuma turvalisus, selle võimalused ja Seccomp

BPF pakub võimsat viisi tuuma laiendamiseks ilma stabiilsuse, turvalisuse ja kiiruseta. Just sellepärast mõtlesid tuuma arendajad, et oleks suurepärane kasutada selle mitmekesisust protsesside isoleerimise parandamiseks Seccompis, rakendades BPF poolt toetatud Seccomp filtreid, tuntud ka kui Seccomp BPF. Selles peatükis räägime, mis on Seccomp ja kuidas seda rakendatakse. Seejärel õpite, kuidas kirjutada Seccomp filtreid BPF programmide abil. Pärast seda vaatame sisse ehitatud BPF lõkse, mis on olemas Linuxi turvamuudatustes.

Linuxi turvamuudatused (LSM) on platvorm, mis pakub komplekti funktsioone, mida saab rakendada erinevate turvamudelite standardiseeritud rakendamiseks. LSM-i saab kasutada otse tuuma lähtekoodide puus, näiteks Apparmor, SELinux ja Tomoyo.

Alustame arutelu Linuxi võimaluste üle.

Võimalused

Linuxi võimekuse tuum seisneb selles, et peate andma tavalisele protsessile õiguse teatud ülesande täitmiseks, kuid ilma et peaksite selleks kasutama suidi, või muul viisil muutma protsessi privileegide taset, vähendades seeläbi rünnaku võimalusi ja andes protsessile võimaluse teatud ülesannete täitmiseks. Näiteks, kui teie rakendus vajab privileegitud portaali avamist, näiteks 80, saate selle asemel, et käivitada protsess root'i alt, anda sellele lihtsalt CAP_NET_BIND_SERVICE õiguse.

Vaadakem Go programmi nimega main.go:

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

See programm teenindab HTTP-serverit pordil 80 (see on privileegitud port). Tüüpiliselt käivitame selle kohe pärast kompileerimist:

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

Kuna me ei anna root õigusi, annab see kood pordi sidumisel tõrke:

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

capsh (võimaluste haldamise shell) on tööriist, mis käivitab shelli teatud õiguste komplektiga.

Selles olukorras, nagu juba mainitud, ei pea me andma täielikku root õiguste komplekti, vaid saame lubada privileegitud portide sidumise, andes õiguse cap_net_bind_service, koos kõigi muude õigustega, mis programmil juba on. Selleks võime oma programmi paigutada capsh-i:

# 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"

Vaatame seda käsklust veidi lähemalt.

• capsh — kasutame capshi shellina.
• —caps=’cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep’ — kuna me peame muutma kasutajat (me ei soovi käivitada root õigustega), määrame cap_net_bind_service ja õiguse sisuliselt muuta kasutaja ID-d root'ilt nobody'le, nimelt cap_setuid ja cap_setgid.
• —keep=1 — soovime säilitada määratud õigused, kui oleme vahetanud konto root'ilt.
• —user=«nobody» — programmi käivitavaks lõppkasutajaks on nobody.
• —addamb=cap_net_bind_service — määrame seotud õiguste puhastamise pärast vahetamist root režiimist.
• — -c ". /capabilities" — lihtsalt käivitame programmi.

Seotud õigused on erilised õigused, mis pärandatakse allprogrammidele, kui praegune programm täidab neid execve() abil. Päranduda võivad ainult õigused, mis on määratud kui seotud, või teisisõnu, kui keskkonna õigused.

Tõenäoliselt olete huvitatud, mida tähendab +eip võimaluse näitamisel valikus —caps. Need lipud määravad, et võimalus:

- peab olema aktiveeritud (p);

- on rakendamiseks saadaval (e);

- võib olla pärandatud alamprotsesside poolt (i).

Kuna tahame kasutada cap_net_bind_service'i, peame seda tegema lipuga e. Seejärel käivitame käsurealt shelli. Tulemuseks on, et käivitatakse capabilities binaarfail ja peame selle märkima lipuga i. Lõpuks tahame, et võimalus oleks aktiveeritud (oleme selle teinud, muutes UID-d) p abil. See näeb välja nagu cap_net_bind_service+eip.

Saate tulemuse kontrollida ss abil. Lühendame väljundit, et see mahuks lehele, kuid see näitab seotud porti ja kasutaja ID-d, mis ei ole 0, antud juhul 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

Sel juhul kasutasime capsh, kuid saate shelli kirjutada ka libcap'i abil. Lisainformatsiooni saamiseks vaadake man 3 libcap.

Programmi kirjutamisel ei tea arendaja üsna sageli ette, millised õigused on programmil käitamise ajal vajalikud; veelgi enam, uutes versioonides võivad need õigused muutuda.

Meie programmi õiguste paremaks mõistmiseks võime võtta tööriista BCC capable, mis seadistab kprobe funktsiooni kernelis 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

Sama saab saavutada, kasutades bpftrace'i ühe reaga kprobe funktsiooni kernelis 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

See kuvab midagi sellist, kui meie programmi õigused on aktiveeritud pärast 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

Viies veerg on õigused, mida protsess vajab, ja kuna need väljavõtted sisaldavad ka mitteauditeeritud sündmusi, näeme kõiki mitteauditeeritud kontrolle ja lõpuks nõutud õigust, mille auditi lipp (viimane väljundis) on seadistatud 1. Meid huvitav võimalus on CAP_NET_BIND_SERVICE, mis on määratletud konstandina kernelis allikas koodis failis include/uapi/linux/ability.h identifikaatoriga 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">

Võimalusi kasutatakse sageli konteinerite, nagu runC või Docker, töö ajal, et need töötaksid privileegita režiimis, kuid neile lubatakse ainult need võimalused, mis on vajalikud enamiku rakenduste käivitamiseks. Kui rakendusele on vajalikud teatud võimalused, saab Dockeris need lubada, kasutades --cap-add:

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

See käsk annab konteinerile võimaluse CAP_NET_ADMIN, mis võimaldab tal seadistada võrgu linki, et lisada dummy0 liides.

Järgmises osas on näidatud, kuidas kasutada selliseid võimalusi nagu filtreerimine, kuid teise meetodi abil, mis võimaldab meil oma filtreid programmeerimislikult rakendada.

Seccomp

Seccomp tähendab Secure Computing, see on turbetase, mis on rakendatud Linuxi tuumas ja võimaldab arendajatel filtreerida teatud süsteemikõnesid. Kuigi Seccomp on võrreldav Linuxi võimalustega, muudab selle võime hallata teatud süsteemikõnesid selle palju paindlikumaks.

Seccomp ja Linuxi võimalused ei välista üksteist, neid kasutatakse sageli koos, et saada kasu mõlemast lähenemisviisist. Näiteks võidakse soovi korral anda protsessile võimalus CAP_NET_ADMIN, kuid mitte lubada tal vastu võtta ühendusi socketi kaudu, blokeerides süsteemikõned accept ja accept4.

Seccomp filtreerimise meetod põhineb BPF filteritel, mis töötavad režiimis SECCOMP_MODE_FILTER, ning süsteemikõnede filtreerimine toimub samamoodi nagu pakettide puhul.

Seccomp filtrid laaditakse prctl kasutades operatsiooniga PR_SET_SECCOMP. Need filtrid on BPF programmide kujul, mis käivitatakse iga Seccomp paketi jaoks, mis esitatakse seccomp_data struktuuri abil. See struktuur sisaldab arhitektuuri, protsessori käskluse suunajat süsteemikõne ajal ja maksimaalselt kuut süsteemikõne argumenti, väljendatud kui uint64.

Nii näeb välja seccomp_data struktuur Linuxi tuuma allikakoodis failis linux/seccomp.h:

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

Nagu näha sellest struktuurist, saame filtreerida süsteemikõne, selle argumentide või nende kombinatsiooni järgi.

Pärast iga paketi vastuvõtmist peab Seccomp filter teostama töötlemise, et teha lõplik otsus ja teavitada tuuma, mida edasi teha. Lõplik otsus väljendatakse ühe tagastatud väärtuse (olekukoodi) kaudu.

— SECCOMP_RET_KILL_PROCESS — kogu protsessi lõpetamine vahetult pärast süsteemi kõne filtreerimist, mis seetõttu ei toimu.

— SECCOMP_RET_KILL_THREAD — praeguse niidi lõpetamine vahetult pärast süsteemi kõne filtreerimist, mis seetõttu ei toimu.

— SECCOMP_RET_KILL — alias SECCOMP_RET_KILL_THREAD, jäetud tagurpidi ühilduvuse säilitamiseks.

— SECCOMP_RET_TRAP — süsteemi kõne on keelatud ja signaal SIGSYS (Vale süsteemi kõne) saadetakse selle kõne teinud protsessile.

— SECCOMP_RET_ERRNO — süsteemi kõne ei toimu ja osa tagastatavast väärtusest filtrist SECCOMP_RET_DATA edastatakse kasutajaruumi väärtusena errno. Olenevalt veast tagastatakse erinevad errno väärtused. Veanumbrite loetelu on järgmises osas.

— SECCOMP_RET_TRACE — kasutatakse ptrace jälgijale teavitamiseks — PTRACE_O_TRACESECCOMP süsteemi kõnede püüdmiseks, et näha ja juhtida seda protsessi. Kui jälgijat ei ole ühendatud, tagastatakse viga, errno seadistatakse -ENOSYS ja süsteemi kõne ei toimu.

— SECCOMP_RET_LOG — süsteemi kõne on lubatud ja registreeritud logisse.

— SECCOMP_RET_ALLOW — süsteemi kõne on lihtsalt lubatud.

ptrace on süsteemi kõne jälgimismehhanismide rakendamiseks protsessis, mida nimetatakse tracee, võimaldades jälgida ja kontrollida protsessi täitmist. Jälgimisprogramm saab tõhusalt mõjutada täitmist ja muuta tracee mälu registreid. Seccomp kontekstis kasutatakse ptrace'i, kui käivitatakse SECCOMP_RET_TRACE oleku kood, seega võib jälgija takistada süsteemi kõne täitmist ja rakendada oma loogikat.

Seccomp vead

Aeg-ajalt töötades Seccompiga võite kokku puutuda erinevate vigadega, mida identifitseeritakse tagastatud väärtuse SECCOMP_RET_ERRNO tüübi järgi. Vea teatamiseks tagastab süsteemi kõne seccomp -1 asemel 0.

Järgmised vead on võimalikud:

— EACCESS — kutsuvälistel ei ole lubatud süsteemikõnet teha. See toimub tavaliselt seetõttu, et tal puuduvad CAP_SYS_ADMIN õigused või ei ole prctl abil seatud no_new_privs (sellest räägime hiljem);

— EFAULT — edastatud argumentidel (args struktuuris seccomp_data) ei ole kehtivat aadressi;

— EINVAL — siin võib olla neli põhjust:

- taotletav operatsioon on teadmata või ei toeta tuuma praeguses konfigureerimises;

- määratud lipud on taotletud operatsiooni jaoks kehtetud;

- operatsioon hõlmab BPF_ABS, kuid määratletud nihkega on probleeme, mis võivad ületada seccomp_data struktuuri suuruse;

- filtrisse edastatud käskude arv ületab maksimaalse;

— ENOMEM — programmiks piisavalt mälu pole;

— EOPNOTSUPP — operatsioon näitas, et SECCOMP_GET_ACTION_AVAIL toiming oli saadaval, kuid tuum ei toeta argumentides tagastamist;

— ESRCH — teise niidi sünkroonimisega tekkis probleem;

— ENOSYS — ei ole jälgijat, mis oleks seotud SECCOMP_RET_TRACE toiminguga.

prctl on süsteemikõne, mis võimaldab kasutajataseme programmil hallata (seada ja saada) konkreetseid protsessi aspekte, nagu baitide järjestus, niitide nimed, kaitstud arvutuskeskkonna režiim (Seccomp), õigused, Perf sündmused jne.

Seccomp võib tunduda nagu liivakasti tehnoloogia, kuid see ei ole nii. Seccomp on utiliit, mis võimaldab kasutajatel arendada liivakasti mehhanismi. Nüüd vaatame, kuidas luua kasutaja suhtlemisprogramme, kasutades filtreid, mida kutsutakse otse süsteemikõne Seccomp kaudu.

BPF Seccomp filtrite näide

Siin näitame, kuidas ühendada kaks varem arutatud toimingut, nimelt:

— kirjutame Seccomp BPF programmi, mis rakendatakse filtrina erinevate tagastuskoodidega sõltuvalt vastuvõetud otsustest;

— laadime filtri, kasutades prctl.

Esmalt on vajalikud pealkirjad standardraamatukogust ja Linuxi tuumast:

#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>

Enne kui üritame seda näidet täita, peame veenduma, et tuum on kompileeritud CONFIG_SECCOMP ja CONFIG_SECCOMP_FILTER seadistustega, mis on seadistatud y. Töömasinas saab seda kontrollida järgmiselt:

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

Koodi ülejäänud osa koosneb install_filter funktsioonist, mis jaguneb kaheks osaks. Esimene osa sisaldab meie BPF filtreerimisjuhiseid:

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),
  };

Juhiseid seadistatakse BPF_STMT ja BPF_JUMP makrode abil, mis on määratud failis linux/filter.h.
Vaatame juhiseid üle.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) — süsteem laadib ja kogub BPF_LD abil sõnaformaadis BPF_W, paketid asuvad fikseeritud nihkega BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) — kontrollib BPF_JEQ abil, kas arhitektuuri väärtus BPF_K akumulaatoris on võrdselt arch-iga. Kui jah, siis liigub nihkega 0 järgmise juhiseni, vastasel juhul, et genereerida viga, hüppab nihkega 3 (antud juhul), kuna arch ei ühti.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) — laadib ja kogub BPF_LD abil sõnaformaadis BPF_W, mis on süsteemikutsumise number, sisaldudes fikseeritud nihkega BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — võrdleb süsteemikutsumise numbrit muutuja nr väärtusega. Kui need on võrdsed, liigub see järgmise juhiseni ja keelab süsteemikutsumise, vastasel juhul lubab süsteemikutsumise SECCOMP_RET_ALLOW abil.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)) — lõpetab programmi BPF_RET abil ja tekitab viga SECCOMP_RET_ERRNO koos numbriga muutuja err.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) — lõpetab programmi BPF_RET abil ja lubab süsteemikutsumise täitmise SECCOMP_RET_ALLOW abil.

SECCOMP ON CBPF
Võib-olla curiositeedist, miks kasutatakse käsujuhendi nimekirja, mitte ELF objektkomplekti või C programmid, mis on JIT-ga kompileeritud.

Sellel on kaks põhjust.

• Esiteks rakendab Seccomp cBPF-i (klassikaline BPF), mitte eBPF-i, mis tähendab: tal pole registreid, vaid ainult akumulaator viimase arvutustulemuse hoidmiseks, nagu võib näha näites.

• Teiseks, Seccomp võtab otse BPF-i käsu massiivi näitaja ja mitte midagi muud. Makrod, mida me kasutasime, aitavad lihtsalt neid käske programmeerijatel mugavas vormis näidata.

Kui vajate lisabi selle kogumiga arusaamiseks, kaaluge pseudokoodi, mis teeb sama:

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

Pärast filtri koodi määramist socket_filteri struktuuris tuleb määrata sock_fprog, mis sisaldab koodi ja arvutatud filtri pikkust. See andmestruktuur on vajalik edasiste protsesside kuulutamise argumendina:

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

Jätkub vaid üks asi, mida teha install_filter funktsioonis — laadida programm ise! Selleks kasutame prctl, võttes valikuks PR_SET_SECCOMP, et siseneda kaitstud arvutuste režiimi. Seejärel määrame režiimile, et laadida filter SECCOMP_MODE_FILTER, mis sisaldub sock_fprog tüüpi muutuja prog sees:

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

Lõpuks saame kasutada meie install_filter funktsiooni, kuid enne seda peame kasutama prctl lause PR_SET_NO_NEW_PRIVS seadmiseks jooksva protsessiga, vältides seega olukorda, kus alamprotsessidel on rohkem õigusi kui vanematel. Samal ajal saame teha järgmisi prctl kutsungeid install_filter funktsioonis, ilma et oleks vaja root õigusi.

Nüüd saame kutsuda install_filter funktsiooni. Blokeerime kõik süsteemi kutsungid write, mis puudutavad X86-64 arhitektuuri, ja anname lihtsalt loa, mis blokeerib kõik katsed. Filtri seadistamise järel jätkame täitmist, kasutades esimest argumenti:

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]);
 }

Alustame. Meie programmi kompileerimiseks võime kasutada kas clang või gcc, igal juhul on see lihtsalt main.c faili kompileerimine ilma eriliste valikuteta:

clang main.c -o filter-write

Kuidas juba mainitud, oleme blokeerinud kõik kirjutamised programmis. Selle kontrollimiseks on vajalik programm, mis midagi väljundab — ls tundub hea kandidaadina. Niimoodi käitub ta tavaliselt:

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

Suurepärane! Nii näeb välja meie kestaprogrammi kasutamine: me edastame lihtsalt programmi, mida soovime testida, esimese argumendina:

.\/filter-write "ls -la"

Pärast täitmist annab see programm täiesti tühja väljundi. Siiski saame rakendada strace'i, et näha, mis juhtub:

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

Tulemused on oluliselt lühendatud, kuid vastav osa näitab, et kirjed blokeeritakse EPERM veaga – just see, mille me seadistasime. See tähendab, et programm ei väljasta midagi, kuna ei pääse juurde süsteemikutsest write:

[pid 25099] write(2, "ls: ", 4) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "write error", 11) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "n", 1) = -1 EPERM (Operation not permitted)

Nüüd mõistate, kuidas Seccomp BPF töötab, ja teil on hea ettekujutus sellest, mida selle abil saavutada saab. Kuid kas poleks tore saavutada sama ka eBPF abil, et kasutada selle kogu võimet?

Mõeldes eBPF programmidele, arvavad enamik inimesi, et nad kirjutavad need lihtsalt ja laadivad administraatori õigustega üles. Kuigi see väide on üldiselt tõsi, rakendab kernel erinevatel tasanditel eBPF objektide kaitseks mehanisme. Need mehhanismid on tuntud kui BPF LSM lõksud.

BPF LSM lõksud

Süsteemsete sündmuste arhitektuurist sõltumatu kontrolli seadmiseks rakendab LSM lõksude kontseptsiooni. Tehniliselt on lõksukutse sarnane süsteemikutsumisega, kuid sõltumatu süsteemist ja integreeritud infrastruktuuri. LSM pakub uut kontseptsiooni, mille abstraktsioonitase aitab vältida probleeme, mis võivad tekkida süsteemikutsete käsitlemisel erinevates arhitektuurides.

Raamatute kirjutamise ajal oli kernelil seitse BPF programmidega seotud lõksu ning SELinux — ainus sisseehitatud LSM, mis neid rakendab.

Lõksude allikakood on paigutatud kernelipuu faili 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);

Iga neist kutsutakse välja erinevates täitmise etappides:

— security_bpf — teostab esialgse kontrolli tehtud süsteemikõnede BPF;

— security_bpf_map — kontrollib, kui südamik tagastab failideskripti kaardi jaoks;

— security_bpf_prog — kontrollib, kui südamik tagastab failideskripti eBPF programmi jaoks;

— security_bpf_map_alloc — kontrollib, kas turvaväli on kaardid BPF sees algatatud;

— security_bpf_map_free — kontrollib, kas turvaväli kaardid BPF sees puhastatakse;

— security_bpf_prog_alloc — kontrollib, kas turvaväli on BPF programmides algatatud;

— security_bpf_prog_free — kontrollib, kas turvaväli BPF programmides puhastatakse.

Nüüd, nähes seda kõike, mõistame: LSM BPF püüdmiste idee on see, et need saavad kaitsta igat eBPF objekti, tagades, et ainult need, kellel on vastavad privileegid, saavad kaardid ja programmide üle teostada toiminguid.

Elulookirjeldus

Turvalisus ei ole midagi, mida saad universaalse viisina rakendada kõigile, mida soovid kaitsta. Oluline on suutlikkus kaitsta süsteeme erinevatel tasanditel ja erinevate viisidega. Usugu või mitte, parim viis süsteemi turvamiseks on organiseerida erinevad kaitsetasemed erinevatest positsioonidest, et ühe taseme turvade vähenemine ei lubaks pääseda kogu süsteemile. Südamike arendajad on teinud suurepärast tööd, pakkudes meile erinevaid kihte ja suhtlemispunkte. Me loodame, et oleme andnud teile hea ülevaate sellest, mis need kihid on ja kuidas kasutada BPF programme nende käsitlemiseks.

Autoritest

David Calavera on Netlify tehniline direktor. Ta on töötanud Dockeris tugiteenustes ja osalenud Runci, Go ja BCC tööriistade arendamises, samuti muudes avatud lähtekoodiga projektides. Ta on tuntud oma töö eest Dockerite ja Docker-pluginte ökosüsteemi arendamisel. David armastab väga flame graph'e ja püüab alati optimeerida jõudlust.

Lorenzo Fontana töötab Sysdigi tarkvaraarendajate meeskonnas, kus ta tegeleb peamiselt Falco projektiga – Cloud Native Computing Foundation'i algatusega, mis tagab konteinerite käitamise keskkonna turvalisuse ja anomaaliate tuvastamise läbi kerneli mooduli ja eBPF-i. Tema huvi on jaotatud süsteemid, tarkvaraga määratud võrgud, Linuxi kerneli ja jõudluse analüüs.

» Raamatuga saab lähemalt tutvuda kirjastuse veebisaidil
» Sisukord
» Lõik

Habr kasutajatele on 25% allahindlus kupongi abil — Linux

Paberkoopia eest maksmise korral saadetakse elektrooniline raamat e-posti teel.

Allikas: habr.com