Raamat „BPF Linuxi jälgimiseks”

Tere, Habrikad! BPF virtuaalmasin on üks Linuxi tuuma olulisemaid komponente. Selle õige rakendamine võimaldab süsteemitehnikutel tuvastada rikkeid ja lahendada isegi kõige keerulisemaid probleeme. Te õpite looma programme, mis jälgivad ja muudavad tuuma käitumist, rakendate turvaliselt koodi tuuma sündmuste jälgimiseks ja palju muud. David Calavera ja Lorenzo Fontana aitavad teil avastada BPF võimalusi. Laiendage oma teadmisi jõudluse, võrkude ja turvalisuse optimeerimise kohta. - Kasutage BPF tuuma Linuxi käitumise jälgimiseks ja muutmiseks. - Rakendage koodi sündmuste turvaliseks jälgimiseks tuumas - ilma tuuma taascompyleerimise või süsteemi taaskäivitamiseta. - Kasutage mugavaid C, Go või Python koodi näiteid. - Hallake olukordi, valdav programmist BPF elu tsüklit.

Linuxi tuuma turvalisus, selle võimalused ja Seccomp

BPF pakub jõulise viisi tuuma laiendamiseks, säilitades samal ajal stabiilsuse, turvalisuse ja kiirus. Sel põhjusel mõtlesid tuumaarendajad, et oleks tore kasutada selle paindlikkust protsesside isoleerimise parandamiseks Seccompis, rakendades Seccompi filtreid, mida toetavad BPF programmid, tuntud ka kui Seccomp BPF. Selles peatükis käsitleme, mis on Seccomp ja kuidas seda rakendatakse. Seejärel õpid, kuidas kirjutada Seccompi filtreid BPF programmide abil. Pärast seda vaatame üle BPF-i sisseehitatud lõksud, mis on tuumas olemas Linuxi turvemoodulite jaoks.

Linuxi turvemoodulid (LSM) on platvorm, mis pakub funktsioonide kogumit, mida saab rakendada erinevate turvamodelide standardiseeritud elluviimiseks. LSM-i saab kasutada otseselt tuuma allika puus, näiteks Apparmor, SELinux ja Tomoyo.

Alustame Linuxi võimaluste arutelust.

Võimalused

Linuxi võimaluste olemus seisneb selles, et peate andma tavalisest protsessist väljaspool privileege teatud ülesande täitmiseks õiguse, kuid ilma suid kasutamata või muul viisil tegemata protsessi privileeritud, vähendades rünnakute võimalusi ja võimaldades protsessil teatud ülesandeid täita. Näiteks kui teie rakendusel on vaja avada privileegitud port, ütleme, 80, siis võite lihtsalt anda sellele õiguse CAP_NET_BIND_SERVICE, selle asemel et käivitada protsess root kasutajana.

Vaadake 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). Tavaliselt käivitame selle kohe pärast kompileerimist:

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

Kuid kuna me ei anna root õigusi, annab see kood porti sidumisel vea:

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

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

Sel juhul, nagu mainitud, saame täielike root-õiguste asemel lubada privileegitud portide sidumist, andes cap_net_bind_service õiguse koos kõigi teistega, mis programmis juba on. Selle jaoks saame meie 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äsku veidi lähemalt.

• capsh — kasutame capsh-i kui shell’i.
• —caps=’cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep’ — kuna peame kasutajat vahetama (me ei soovi töötada root-õigustega), määrame cap_net_bind_service ja võimaluse tegelikult muuta kasutaja identifikaatorit root’ilt nobody’ks, nimelt cap_setuid ja cap_setgid.
• —keep=1 — soovime säilitada seatud õigused pärast vahetamist root-kontolt.
• —user=«nobody» — programmi käivitav lõppkasutaja on nobody.
• —addamb=cap_net_bind_service — seame seotud õiguste puhastamise pärast vahetamist root-režiimist.
• — -c "./capabilities" — lihtsalt käivitame programmi.

Seotud õigused on eriline õiguste liik, mis pärandatakse alamrakenduste poolt, kui praegune rakendus neid käivitab execve() kaudu. Pärandada saab ainult õigusi, mis on lubatud kui seotud, või teisisõnu, kui keskkonna õigusi.

Tõenäoliselt olete huvitatud, mida +eip tähendab pärast õiguse määramist valikus —caps. Need lipud määravad, kas õigus:

- peab olema aktiveeritud (p);

- on kohaldatav (e);

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

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

Saate tulemuse kontrollida ss abil. Veidi lühendame väljundit, et see mahtuks leheküljele, kuid see näitab seotud porti ja kasutaja identifitseerimist, 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

Selles näites kasutasime capsh, kuid saate luua ka shelli libcap abil. Lisainformatsiooni saamiseks vaadake man 3 libcap.

Programmi kirjutamise ajal ei tea arendaja sageli ette kõiki võimalusi, mida programm jooksutamise ajal vajab; veelgi enam, uutes versioonides võivad need võimalused muutuda.

Kuna meie programmi võimalusi paremini mõista, võtame näiteks tööriista BCC capable, mis seadistab kprobe tuuma funktsioonile 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 tulemuse saavutamiseks saame kasutada bpftrace'i ühe reaga kprobe't tuuma funktsiooni cap_capable puhul:

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

See väljastab midagi järgmist, kui meie programmi võimalused aktiveeritakse pärast kprobe't:

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 võimalused, mida protsess vajab, ja kuna need väljundid sisaldavad ka mitteauditeeritud sündmusi, näeme kõiki mitteauditeeritud kontrolle ja lõpuks vajalikke võimalusi, mille auditeerimise lipp (viimane väljundis) on seatud 1. Meid huvitav võimalus on CAP_NET_BIND_SERVICE, mis on määratud pidevaks vaates 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 käitamisel, näiteks runC või Docker, et need töötaksid ebamugavates tingimustes, kuid lubada ainult neid võimalusi, mis on vajalikud enamiku rakenduste käitamiseks. Kui rakendusele on vaja teatud võimalusi, saab Dockeris neid tagada —cap-add abil:

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ühenduse dummy0 liidese lisamiseks.

Järgmises osas näitatakse selliste võimaluste kasutamist nagu filtreerimine, kuid teise meetodi abil, mis võimaldab meil programmiliselt rakendada oma filtreid.

Seccomp

Seccomp tähendab Secure Computing, see on turvalisuse tase, mis on rakendatud Linuxi tuumas, võimaldades arendajatel filtreerida teatud süsteemi kõnesid. Kuigi Seccomp on võrreldav Linuxi võimalustega, muudab selle võime hallata teatud süsteemi kõ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õite soovida anda protsessile õiguse CAP_NET_ADMIN, kuid mitte lubada tal luua ühendusi soketi kaudu, blokeerides süsteemi kõned accept ja accept4.

Seccompi filtreerimisviis põhineb BPF filtritel, mis töötavad SECCOMP_MODE_FILTER režiimis, ja süsteemi kõnede filtreerimine toimub sama moodi nagu pakettide puhul.

Seccomp filtrid laaditakse prctl'i abil PR_SET_SECCOMP operatsiooni kaudu. Need filtrid on BPF programmi kujul, mis täidetakse iga Seccomp paketi jaoks, mis esitatakse seccomp_data struktuuri kaudu. See struktuur sisaldab arhitektuuri viidet, protsessori käsu näitajat süsteemikutsumise ajal ja kuni kuut süsteemikutsumise argumenti, väljendatuna uint64 formaadis.

Nii näeb välja seccomp_data struktuur tuuma lähtekoodis 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üsteemikutsumise, selle argumentide või nende kombinatsiooni järgi.

Pärast iga Seccomp paketi vastuvõtmist peab filter tegema töötlemise, et teha lõplik otsus ja teavitada tuuma, mida edasi teha. Lõplik otsus väljendatakse ühes tagastatavatest väärtustest (olekukoodidest).

— SECCOMP_RET_KILL_PROCESS — kogu protsessi kohene lõpetamine pärast süsteemikutsumise filtreerimist, mida ei täideta.

— SECCOMP_RET_KILL_THREAD — praeguse thread'i kohene lõpetamine pärast süsteemikutsumise filtreerimist, mida ei täideta.

— SECCOMP_RET_KILL — alias SECCOMP_RET_KILL_THREAD, jäetud tagasipöörduvuse huvides.

— SECCOMP_RET_TRAP — süsteemikutsung on keelatud ja SIGSYS (Bad System Call) signaal saadetakse kutsuvat ülesannet.

— SECCOMP_RET_ERRNO — süsteemikutsungit ei täideta ja osa tagastatavast väärtusest filtrist SECCOMP_RET_DATA edastatakse kasutaja ruumi errno väärtusena. Erinevad errno väärtused tagastatakse sõltuvalt vigade põhjusest. Vigade numbrite loetelu on toodud järgmises jaotises.

— SECCOMP_RET_TRACE — kasutatakse ptrace jälgija teavitamiseks — PTRACE_O_TRACESECCOMP, et katkestada, kui süsteemikutsung käivitatakse ja näha ning kontrollida seda protsessi. Kui jälgijat ei ole ühendatud, tagastatakse viga, errno seadistatakse väärtusele -ENOSYS ja süsteemikutsungit ei täideta.

— SECCOMP_RET_LOG — süsteemikutsung on lubatud ja logitakse.

— SECCOMP_RET_ALLOW — süsteemikutsung on lihtsalt lubatud.

ptrace — see süsteemikutsung jälgimise mehhanismide rakendamiseks protsessis, nimetatakse tracee, võimaldades jälgida ja kontrollida protsessi täitmist. Jälgimisprogramm suudab tõhusalt mõjutada ja muuta tracee mälu registreid. Seccomp kontekstis kasutatakse ptrace, kui käivitatakse SECCOMP_RET_TRACE olek, seetõttu saab jälgija takistada süsteemikutsungi täitmist ja rakendada oma loogikat.

Seccompi vead

Aeg-ajalt, töötades Seccompiga, võite kokku puutuda erinevate vigadega, mis tuvastatakse SECCOMP_RET_ERRNO tüüpi tagastatava väärtuse kaudu. Veast teatamiseks tagastab süsteemikutsung seccomp -1 asemel 0.

Võimalikud järgmised vead:

— EACCESS — kutse pooled ei ole lubatud süsteemikutsungit tegema. See juhtub tavaliselt seetõttu, et neil ei ole privileege CAP_SYS_ADMIN või no_new_privs ei ole prctl abil seatud (sellest räägime hiljem);

— EFAULT — edastatud argumendid (args struktuuris seccomp_data) ei omada kehtivat aadressi;

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

- taotletud operatsioon on teadmata või tuuma poolt antud konfiguratsioonis mittekohaldatav;

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

- operatsioon hõlmab BPF_ABS, kuid mõningaid probleeme on määratud offsetiga, mis võib ületada struktuuri seccomp_data suurust;

- filtrisse edastatud käskude arv ületab maksimaalse arvu;

— ENOMEM — programmiks vajaliku mälu puudumine;

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

— ESRCH — probleemi tekkimine teise niidi sünkroniseerimisel;

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

prctl on süsteemikõne, mis võimaldab kasutaja ruumi programmil hallata (seada ja saada) teatud protsessi spetsiifilisi aspekte, nagu baitide järjekord, tee nimed, kaitstud arvutustasandi režiim (Seccomp), privileegid, Perf üritused jne.

Seccomp võib teile tunduda liivakasti tehnoloogiana, kuid see pole nii. Seccomp on utiliit, mis võimaldab kasutajatel välja töötada liivakasti mehhanismi. Vaatame nüüd, kuidas luua kasutaja interaktsioonide programme, kasutades vahetult Seccomp süsteemikutsumisele kutsutud filtrit.

BPF Seccomp filtri näide

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

— kirjutame Seccomp BPF programmi, mida rakendatakse filtrina erinevate tagastuskoode kasutades vastavalt võetavatele otsustele;

— laadime filtrit, kasutades prctl.

Kuna alguses on vajalikud pealkirjad standardraamatukogust ja Linuxi kernelist:

#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 selle näite täitmist peame veenduma, et kerneli on kompileeritud CONFIG_SECCOMP ja CONFIG_SECCOMP_FILTERga, mille väärtus on y. Töötavas masinas saab seda kontrollida nii:

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

Koodijäänus on install_filter funktsioon, mis koosneb kahest osast. Esimene osa sisaldab meie BPF filtreerimisjuhiste loetelu:

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

Käskluseid seadistatakse BPF_STMT ja BPF_JUMP makrode abil, mis on defineeritud failis linux/filter.h.
Vaatame käsklusi.

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

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) — kontrollib, kasutades BPF_JEQ-d, kas arhitektuuri väärtus konstantse akumulaatori BPF_K sees on võrdsed arch-iga. Kui jah, suundub see nihkega 0 järgmisele käsklusele, vastasel juhul hüppab see nihkega 3 (antud juhul), sest arch ei kattu.

— BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) — laadib ja kogub BPF_LD abil sõnana BPF_W, mis on süsteemi kutsumise number, mis asub fikseeritud nihkega BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — võrdleb süsteemikõne numbrit muutujaga nr. Kui need on võrdsed, liigutakse järgmisele käsule ja keelatakse süsteemikõne; vastasel juhul lubatakse süsteemikõne SECCOMP_RET_ALLOW abil.

— BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)) — lõpetab programmi BPF_RET-ga ja annab tulemuseks SECCOMP_RET_ERRNO veateate numbriga muutujast err.

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

SECCOMP — SEE ON CBPF
Võib-olla huvitab teid, miks kasutatakse koostatud ELF objekti või JIT-iga koostatud C-programmi asemel käskude loendit.

Selleks on kaks põhjust.

• Esiteks, Seccomp rakendab cBPF (klassikaline BPF), mitte eBPF, mis tähendab: puuduvad registrid, on ainult akumulatsioon viimase arvutustulemuse hoidmiseks, nagu näha on näites.

• Teiseks, Seccomp võtab BPF-käskude massiivi otse ja mitte midagi muud. Makrod, mida me kasutasime, aitavad lihtsalt neid käskusid esitada programmaritele mugavas vormis.

Kui vajate täiendavat abi selle kogumi mõistmisel, vaadake 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 filter-koodi määratlemist socket_filter struktuuris on vajalik määratleda sock_fprog, mis sisaldab koodi ja arvutatud filter'i pikkust. Seda andmestruktuuri on vajalik kasutada protsessi töödeklaratsiooni argumendina edaspidi:

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

Viimase asjana tuleb funktsioonis install_filter laadida programm ise! Selleks kasutame prctl-i, valides PR_SET_SECCOMP valikuna, et siseneda kaitstud arvutuste režiimi. Seejärel määrame režiimile filteri laadimise SECCOMP_MODE_FILTER abil, mis on määratud sock_fprog tüüpi muutuja prog:

  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 tuleb aktiveerida prctl, et seadistada PR_SET_NO_NEW_PRIVS praegusele protsessile, vältimaks olukorda, kus alamprotsessid saavad laiemad õigused kui vanemprotsess. Sellega seoses võime teha järgmised prctl kutsed install_filter funktsioonis, omamata root õigusi.

Nüüd saame kutsuda install_filter funktsiooni. Blokeerime kõik write süsteemi kutsed, mis on seotud X86-64 arhitektuuriga, ja anname lihtsalt loa, mis takistab kõiki katseid. Pärast filtri seadistamist 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'i või gcc'd, igal juhul on see lihtsalt main.c faili kompileerimine ilma eriliste valikuteta:

clang main.c -o filter-write

Nagu mainitud, oleme blokeerinud kõik kirjutamised meie programmis. Selle kontrollimiseks on vajalik programm, mis midagi väljastab - ls tundub olevat hea kandidaat. Nii käitub see 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 shell-programmi kasutamine: me edastame lihtsalt testitava programmi esimese argumendina:

./filter-write "ls -la"

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

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

Tulemuse väljaanne on oluliselt lühendatud, kuid vastav osa näitab, et kirjete blokeerimine toimub EPERM viga — just see, mille me seadistasime. See tähendab, et programm ei prikku väljundit, kuna ei saa juurde pääseda süsteemikutsumisele 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 sellega saavutada saab. Kuid kas poleks tore saavutada sama eBPF'i abil, mitte cBPF'iga, et kasutada selle kogu jõud?

Mõeldes eBPF programmidele, arvavad paljud inimesed, et nad lihtsalt kirjutavad need ja laadivad administraatori õigustega üles. Kuigi see väide on enamasti õige, rakendab kernel eBPF objektide kaitsmiseks erinevatel tasanditel komplekti mehhanisme. Neid mehhanisme nimetatakse BPF LSM lõksudeks.

BPF LSM lõksud

Süsteemsete sündmuste arhitektuurist sõltumatu kontrolli tagamiseks rakendab LSM lõksude kontseptsiooni. Tehniliselt lõksukutsumine sarnaneb süsteeminõudmisega, kuid on süsteemist sõltumatu ja integreeritud infrastruktuuriga. LSM pakub uut kontseptsiooni, kus abstraktsioonitase aitab vältida probleeme, mis tekivad süsteeminõudmistega töötamisel erinevates arhitektuurides.

Raamatute kirjutamise hetkel oli kernelil seitse lõksu, mis on seotud BPF programmide ja SELinuxiga — ainus sisseehitatud LSM, mis neid rakendab.

Lõksude lähtekood asub kernelipuudes failis 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 erinevates etappides:

— security_bpf — viib läbi esialgse kontrolli BPF süsteemikutsest;

— security_bpf_map — kontrollib, kui tuum tagastab failideskirja kaardile;

— security_bpf_prog — kontrollib, kui tuum tagastab failideskirja eBPF programmile;

— security_bpf_map_alloc — kontrollib, kas turvaväli on initsialiseeritud BPF kaartide sees;

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

— security_bpf_prog_alloc — kontrollib, kas turvaväli initsialiseeritakse BPF programmide sees;

— security_bpf_prog_free — kontrollib, kas turvaväli puhastatakse BPF programmide sees.

Nüüd, kui me seda kõike näeme, mõistame: LSM BPF häkkerite idee on see, et nad saavad tagada iga eBPF objekti kaitse, tagades, et ainult need, kellel on vastavad volitused, saavad kaarte ja programme töödelda.

Kokkuvõte

Turvalisus ei ole midagi, mida saate universaalselt rakendada kõigile, mida soovite kaitsta. Oluline on suuteline kaitsma süsteeme erinevatel tasanditel ja erinevate meetoditega. Usugu, või mitte, parim viis süsteemi turvamiseks on korraldada erinevad kaitsetasemed erinevatest positsioonidest, et ühe tasandi turvalisuse langus ei võimaldaks pääseda kogu süsteemile. Südamiku arendajad on teinud suurepärase töö, et anda meile erinevate kihtide ja suhtluspunktide kogum. Loodame, et oleme andnud teile hea ülevaate sellest, mis on kihid ja kuidas kasutada BPF programme nende töötamiseks.

Autoritest

David Calavera on tehnilise direktori ametipostil Netlify. Ta on töötanud Docker'i klienditoes ja osalenud Runc, Go ja BCC tööriistade arenduses, samuti teistes avatud lähtekoodiga projektides. Ta on tuntud oma töö poolest Docker'i projektide ja Docker'i pluginakeskuse arendamise valdkonnas. David armastab väga flame graphs'i ja püüdleb pidevalt jõudluse optimeerimise poole.

Lorenzo Fontana töötab avatud lähtekoodiga tarkvaraarendajate meeskonnas Sysdigis, kus ta tegeleb peamiselt Falco projektiga — Cloud Native Computing Foundation'i algatusega, mis tagab konteinerite käituskeskkonna turvalisuse ja anomaaliate avastamise läbi kernel mooduli ja eBPF-i. Ta on kirglik jaotatud süsteemide, programmide määratletud võrkude, Linuxi tuuma ja jõudluse analüüsi vastu.

» Raamatu kohta on täiendavat teavet saadaval väljaandja veebisaidil
» Sisukord
» Lõik

Habr'i lugejatele 25% allahindlus kupongiga — Linux

Paberraamatu eest tasumise korral saadetakse e-raamat e-kirjaga.

Allikas: habr.com