🥇BPF kõige väiksemate jaoks, osa null: klassikaline BPF

Berkeley Packet Filters (BPF) on Linuxi tuumor, mis on juba mitu aastat olnud ingliskeelsete tehniliste väljaannete esikülgedel. Konverentse on täis ettekandeid BPF-i kasutamise ja arendamise kohta. David Miller, Linuxi võrgu alamsüsteemi hooldaja, nimetab oma ettekannet Linux Plumbers 2018. «See ettekanne ei käsitle XDP-d» (XDP on üks BPF-i kasutamise variante). Brendan Gregg peab ettekandeid, mille pealkiri on Linux BPF Superpowers. Toke Høiland-Jørgensen naerab, et tuuma on nüüd microkernel. Thomas Graf reklaamib ideed, et BPF on JavaScript tuuma jaoks..

Habrás ei ole veel süsteemset kirjeldust BPF-ist ja seetõttu püüan ma oma artiklite seerias rääkida tehnoloogia ajaloost, kirjeldada arhitektuuri ja arendusvahendeid, visandada kasutusalad ja BPF-i kasutamise tavad. Selles, nulls artiklis, antakse ülevaade klassikalise BPF-i ajaloost ja arhitektuurist, samuti paljastatakse tööpõhimõtete saladused tcpdump, seccomp, strace, ja palju muud.

BPF-i arendust juhib Linuxi võrgu kogukond, peamised olemasolevad BPF-i rakendused on seotud võrkudega ja seetõttu, lubades @eucariot, nimetas ma seeria "BPF kõige väiksematele", kuulsale seeriale "Võrgud kõige väiksematele".

BPF-i ajalugu lühidalt (c)

Kaasaegne BPF-tehnoloogia on täiustatud ja täiustatud versioon vanast tehnoloogiast, mida nimetatakse nüüd, et vältida segadust, klassikaliseks BPF-iks. Klassikalise BPF-i baasil on loodud tuntud tööriist tcpdump, mehhanism seccomp, samuti vähem tuntud moodul xt_bpf jaoks iptables ja klassifikaator cls_bpf. Kaasaegses Linuxis tõlgitakse klassikalised BPF-programmid automaatselt uude vormi, kuid kasutaja seisukohalt on API jäänud samaks ja klassikalise BPF-i uued rakendused, nagu me selle artikli käigus näeme, on endiselt olemas. Sellepärast, samuti seetõttu, et klassikalise BPF-i ajaloo jälgimine Linuxis näitab, kuidas ja miks see on arenenud kaasaegsesse vormi, otsustasin alustada just klassikalise BPF-i artiklist.

Kaheksakümnendate aastate lõpus huvitusid tuntud Lawrence Berkeley Laboratori insenerid küsimusest, kuidas õigesti filtreerida võrgu pakette tol ajal olemasolevatel seadmetel. Filtreerimise põhiidee, mis algselt realiseeriti CSPF (CMU/Stanford Packet Filter) tehnoloogias, seisnes selles, et filtreerida liigsed paketid nii varakult kui võimalik, st kernelis, kuna see võimaldab mitte kopeerida liigseid andmeid kasutaja ruumi. Käitusaja turvalisuse tagamiseks kasutati kernelis kasutajakoode käitamiseks virtuaalmasinat — liivakasti.

Kuid virtuaalmasinad olemasolevatele filtritele olid projekteeritud töötama kuhja arhitektuuril ja uutel RISC masinatel töö olid vähem efektiivsed. Lõpuks töötas Berkeley Labs'i inseneride jõupingutustel välja uus tehnoloogia BPF (Berkeley Packet Filters), mille virtuaalmasina arhitektuur oli projekteeritud Motorola 6502 protsessori põhjal — tööloom selliste tuntud toodete vältel nagu Apple II või NES. Uus virtuaalmasin suurendas filtrite jõudlust mitmekümne korra võrreldes olemasolevate lahendustega.

BPF masina arhitektuur

Me tutvume masina arhitektuuriga tööalaselt, analüüsides näiteid. Kuid alustuseks ütlemine, et masinal oli kaks kasutajale ligipääsetavat 32-bitist registrit, akumulaator A ja indeksregister X, 64 baiti mälu (16 sõna), mis oli kirjutamiseks ja edaspidiseks lugemiseks saadaval, ning väike käskude süsteem nende objektidega töötamiseks. Programmides olid saadaval ka hüppeinstruktsioonid tingimuslike lause rakendamiseks, kuid programmi õigeaegse lõpetamise tagamiseks tohtis hüpata ainult edasi, st konkreetselt oli keelatud luua tsükleid.

Masina töö üldskeem on järgmine. Kasutaja koostab programmi BPF arhitektuurile ja, kasutades mingit kernelimehhanismi (näiteks süsteemi kõne), laadib ja ühendab programmi mingi sündmuste generaatoriga kernelis (näiteks sündmus — järgmise paketi saabumine võrgu kaardile). Sündmuse tekkimisel käivitab kernel programmi (näiteks tõlgendi kaudu), samal ajal kui masina mälu on kooskõlas mingi tuuma mälu tuumast (näiteks saabunud paketi andmetest).

Ülaltoodud piisab meile, et alustada näidete uurimist: vajaduse korral tutvume süsteemi ja käskude vorminguga. Kui aga soovite kohe teada saada virtuaalmasina käskude süsteemi ja selle kõikidest võimalustest, siis saate lugeda originaalartiklit BSD paketikott ja/või faili esimesest poolest Dokumentatsioon/networking/filter.txt tuuma dokumentatsioonist. Lisaks saab tutvuda esitlustega libpcap: Paketi puuri arhitektuur ja optimeerimise metodoloogia, kus McCanne, üks BPF autoritest, räägib selle loomise ajaloost libpcap.

Käime nüüd läbi kõik olulised klassikalise BPF rakendused Linuxis: tcpdump (libpcap), seccomp, xt_bpf, cls_bpf.

tcpdump

BPF arendamine toimus samaaegselt tuntud paketikottide filtreerimise tööriista - kõigile teada oleva utiliidi - arendamisega. tcpdump. Kuna see on vanim ja kõige tuntum klassikalise BPF rakendustest, saadaval paljudes operatsioonisüsteemides, alustame tehnoloogia uurimist just sellest.

(Kõiki selle artikli näiteid jooksutasin Linuxis 5.6.0-rc6. Mõnede käskude väljund on muudetud suurema loetavuse saavutamiseks.)

Näide: jälgime IPv6 pakette

Kujutage ette, et soovime jälgida kõiki IPv6 pakette liideses eth0. Selleks saame käivitada programmi tcpdump lihtsa filtriga ip6:

$ sudo tcpdump -i eth0 ip6

Selle juures tcpdump kompileerib filtri ip6 BPF arhitektuuri baitkoodiks ja saadab selle tuumale (vt üksikasju peatükis Tcpdump: laadimine). Laaditud filter käivitatakse iga paketi jaoks, mis läbib liidest eth0. Kui filter tagastab mitte nullväärtuse n, siis n paketi baitidest kopeeritakse kasutaja ruumi ja näeme seda väljundis tcpdump.

Selgub, et saame lihtsalt teada, millist baitkoodi tuumale saatsime tcpdump kasutades tcpdump, kui käivitame selle valikuga -d:

$ sudo tcpdump -i eth0 -d ip6
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 3
(002) ret      #262144
(003) ret      #0

Esimesel real käivitame käsu ldh [12], mis dešifreeritakse kui "lae registrisse A pool-sõna (16 bitti), mis asub aadressil 12" ja ainus küsimus on, millisest mälust me räägime? Vastus on see, et aadressil x alustatakse (x+1)-ndat baiti analüüsitavast võrgu paketist. Me loeme pakette Etherneti liidese kaudu eth0, ja see tähendab tähendab, et pakett näeb välja järgmine (lihtsuse huvides oletame, et pakett ei sisalda VLAN silte):

       6              6          2
|Siht MAC|Allika MAC|Ether Type|...|

Nii et pärast käsu täitmist ldh [12] registreerimise A tuleb välja väli Ether Type — edastatava paketi tüüp, mis sisaldub selles Etherneti raamises. Reedel 1 võrreldame registri sisu A (paketi tüüp) c 0x86dd, ja see tähendab ja see on meie huvi pakkuv IPv6 tüüp. Reedel 1 on lisaks võrdluskäsule veel kaks veergu — jt 2 ja jf 3 — silte, kuhu tuleb liikuda eduka võrdluse korral (A == 0x86dd) ja ebaeduka korral. Nii et eduka juhtumi (IPv6) korral liigume reele 2, ebaeduka korral reele 3. Reedel 3 lõpetab programm koodiga 0 (paketti ei kopeerita), reedel 2 lõpetab programm koodiga 262144 (kopeeri mulle maksimaalselt 256 kilobaiti paketti).

Veidi keerulisem näide: vaatame TCP pakette sihtporti läbi

Vaadake, kuidas filtreerija, mis kopeerib kõik TCP paketid sihtporti 666. Uurime IPv4 juhtumit, kuna IPv6 juhtum on lihtsam. Pärast selle näite uurimist võite harjutusena iseseisvalt uurida IPv6 filtri (ip6 and tcp dst port 666) ja filtri üldise juhtumi (tcp dst port 666). Nii et meie huvi pakkuv filter näeb välja järgmiselt:

$ sudo tcpdump -i eth0 -d ip and tcp dst port 666
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 16]
(008) jeq      #0x29a           jt 9    jf 10
(009) ret      #262144
(010) ret      #0

Mida teevad read 0 ja 1, me juba teame. Reedel 2 oleme juba kontrollinud, et see on IPv4 pakett (Ether Type = 0x800) ja laadime registrisse A paketi 24. baiti. Meie pakett näeb välja nagu

       14            8      1     1
|etherneti pea|ip väljad|ttl|protokoll|...

seega laadime registrisse A IP peaaia Protokoll, mis on mõistetav, sest me tahame kopeerida ainult TCP pakette. Me võrdleme Protokolli 0x6 (IPPROTO_TCP) reedetel 3.

Reedel 4 ja 5 laadime pool sõna, mis asub aadressil 20, ja käsu abil jset kontrollime, kas ega üks kolmest lipukesest — antud maskis jset on kolm kõige tähtsamat bitti puhastamata. Kaks kolme bittide hulgast annavad meile teada, kas pakett on fraktsioonitud IP paketi osa, ja kui jah, kas see on viimane fraktsioon. Kolmas bitt on reserveeritud ja peab olema null. Me ei soovi kontrollida ei täis- ega vigased pakette, seetõttu kontrollime kõiki kolme bitti.

Reede 6 on selle loendi kõige huvitavam. Avaldus ldxb 4*([14]&0xf) tähendab, et laadime registrisse X neljandad madalamad bitid viieteistkümnendas baitis, korrutatud 4. Neljandad madalamad bitid viieteistkümnendas baitis on väli Internet Header Length IPv4 päises, kus salvestatakse päise pikkus sõnades, seetõttu tuleb see hiljem korrutada 4-ga. Huvi pakub, et väljend 4*([14]&0xf) on eriline adresseerimise skeem, mida saab kasutada ainult sellisel kujul ja ainult registri puhul X, st me ei saa öelda ei ldb 4*([14]&0xf) ei ldxb 5*([14]&0xf) (saame ainult märkida teise offseti, näiteks ldxb 4*([16]&0xf)). Selge on, et see adresseerimise skeem lisati BPF just selleks, et jõuda X (indekseerimisregister) IPv4 päise pikkuseni.

Nii et real 7 proovime laadida pool-sõna aadressilt (X+16). Meenutades, et 14 baiti hõlmab Etherneti päist, ja X sisaldab IPv4 päise pikkust, mõistame, et A laaditakse TCP sihtport:

       14           X           2             2
|ethernet header|ip header|source port|destination port|

Lõpuks, real 8 võrdleme sihtporti soovitud väärtusega ja ridadel 9 või 10 tagastame tulemuse — kas kopeerida pakett või mitte.

Tcpdump: laadimine

Eelnevates näidetes ei peatunud me täpselt sellel, kuidas me laadime BPF bytecode'i kernelisse pakettide filtreerimiseks. Üldiselt, tcpdump on see portiteeritud paljudele süsteemidele ja filtreid kasutades tcpdump , täpsemalt — kirjutame kaks funktsiooni: üks pseudo-ristkülikulise maatriksi kasutamisega (mida ei soovitata praktiliselt, kuna see on arvutuslikult keeruline ja ebatavaline), teine maatrikuvõrrandi abil. libpcap. Lühidalt, et panna filter liidesele kasutades libpcap, tuleb teha järgmiselt:

luua tüüpi deskriptor pcap_t liidese nimest: pcap_create,
aktiveerida liides: pcap_activate,
kompileerida filter: pcap_compile,
ühendada filter: pcap_setfilter.

Kuna näha, kuidas funktsioon pcap_setfilter on Linuxis teostatud, kasutame strace (mõned read on eemaldatud):

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

Esimese kahe rea väljundis loome toores soketi kõigi Etherneti kaadrite lugemiseks ja seome selle liidesega eth0. Meie esimesest näitest teame, et filter ip koosneb neljast BPF käsklusest, ja kolmandal real näeme, kuidas läbi SO_ATTACH_FILTER system call setsockopt laadime ja ühendame 4-pikkuse filtri. Just see on meie filter.

On tuleb märkida, et klassikalises BPF-is toimub filtri laadimine ja liitmine alati aatomaarse operatsioonina, samas kui BPF-i uues versioonis on programmi laadimine ja selle sidumine sündmuste generaatoriga ajaliselt eraldatud.

Peidetud tõde

Veidi täielikum versioon väljundist on järgmine:

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

Nagu eespool mainitud, laadime ja liidame meie filtri soketiga real 5, kuid mis toimub ridadel 3 ja 4? Selgub, et see libpcap muretseb meie eest — et meie filtri väljundisse ei satuks pakette, mis sellele ei vasta, raamatukogu liidab vale filtri ret #0 (kõik paketid visata kõrvale), muudab soketi mitteblokeerivaks ja proovib lugeda kõik paketid, mis võisid jääda eelmistelt filtritelt.

Seega, et filtreerida pakette Linuxis klassikalise BPF-i kaudu, on vajalik filter struktuuri tüübina struct sock_fprog ja avatud soket, pärast mida saab filtri soketiga siduda süsteemikõne abil setsockopt.

On huvitav, et filter saab liita igasuguste soketitega, mitte ainult raw. Siin on näide programm, mis lõikab kõik välja, välja arvatud kaks esimest bitti kõigist sissetulevatest UDP datagrammidest. (Kommentaarid olen lisanud koodi, et artiklit mitte koormata.)

Rohkem teavet filtri setsockopt sidumise kohta vt socket(7), ja oma filtrite kirjutamise kohta struct sock_fprog ilma abita tcpdump räägime jaotises BPF-i programmeerimine oma kätega.

Klassikaline BPF ja XXI sajand

BPF lisati Linuxisse 1997. aastal ja püsis kaua aega tööhobuse rollis libpcap ilma eriliste muudatusteta (Linuxi-spetsiifilised muudatused, muidugi, olid, kuid need ei muutnud globaalses pildis midagi). Esimesed tõsised märgid, et BPF hakkab arenema, ilmusid 2011. aastal, kui Eric Dumazet pakkus patš, mis lisas kernelisse Just In Time Compileri — tõlkija BPF-i bytecode-i muundamiseks natiivseks x86_64 koodiks.

JIT kompilaator oli esimeseks muutuste ahelas: 2012. aastal on oli võimalik kirjutada filtreid seccomp, kasutades BPF-i, jaanuaris 2013 ilmus on lisatud moodul xt_bpf, mis võimaldas kirjutada reegleid iptables BPF-i abil, ja oktoobris 2013 ilmus on lisatud ka moodul cls_bpf, võimaldades BPF-i abil liiklusklassifikaatoreid kirjutada.

Kuna võimalused, mille raamatukogu pakub, on piiratud (lihtne näide: filtreer, mis on genereeritud libpcap võib tagastada ainult kaks väärtust — 0 või 0x40000) või ei ole üldse kohaldatavad, nagu seccompi puhul. libpcap Tutvume BPF-i binaarfaili formaadiga, mis on väga lihtne:

BPF-i programmeerimine oma kätega

16 8 8 32 | kood | jt | jf | k |

   Iga käsk võtab 64 bitti, kus esimesed 16 bitti on käsu kood, seejärel kaks 8-bitist lülitust,

jt jf ja , ja 32 bitti argumendi jaoks,, mille tähendus muutub vastavalt käsklusele. Näiteks käsk K, mis lõpetab programmi, omab koodi ret, ja tagastatav väärtus võetakse konstandist 6. C keeles esindatakse ühte BPF-i käsku struktuurina Kstruct sock_filter { __u16 kood; __u8 jt; __u8 jf; __u32 k; }

ja tervet programmi struktuurina

struct sock_fprog { unsigned short len; struct sock_filter *filter; }

Nii et me saame juba kirjutada programme (käskude koodid on meil juba teada

). Nii välja näeb filter [1]struct sock_filter code[] = { { 0x28, 0, 0, 0x0000000c }, { 0x15, 0, 1, 0x000086dd }, { 0x06, 0, 0, 0x00040000 }, { 0x06, 0, 0, 0x00000000 }, }; struct sock_fprog prog = { .len = ARRAY_SIZE(code), .filter = code, }; ip6 API-s esimesest näitest:

prog

Programm saame seaduseselt kasutada funktsioonis setsockopt(sk, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog))

Programme masina koodina kirjutamine ei ole väga mugav, kuid vahel on see vajalik (näiteks silumise, üksuste testide loomise, artiklite kirjutamise ajal jne). Mugavuse huvides määratakse failis

<linux/filter.h> abil abimakrosid — sama näide, mis eespool, võiks ümber kirjutada kui struct sock_filter code[] = { BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12), BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_IPV6, 0, 1), BPF_STMT(BPF_RET|BPF_K, 0x00040000), BPF_STMT(BPF_RET|BPF_K, 0), }

Kuid ka seda varianti ei saa mugavaks nimetada. Nii arvasid ka Linuxi kerneli arendajad, seetõttu võib kernelikataloogist

tools/bpf leida assembleri ja debuggeri klassikalise BPF-i jaoks. Assembleri keel sarnaneb väga silumise väljundiga

, kuid lisaks saame määrata sümboolseid silte. Näiteks programm, mis viskab kõik paketid, välja arvatud TCP/IPv4: tcpdump$ cat /tmp/tcp-over-ipv4.bpf ldh [12] jne #0x800, drop ldb [23] jneq #6, drop ret #-1 drop: ret #0

Vaikimisi genereerib assembler koodi formaadis

Vaikimisi genereerib assembler koodi formaadis , ,..., meie TCP näite puhul saadakse

$ tools/bpf/bpf_asm /tmp/tcp-over-ipv4.bpf
6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 6,6 0 0 4294967295,6 0 0 0,

C programmeerijate mugavuse huvides võib kasutada teistsugust väljundformaati:

$ tools/bpf/bpf_asm -c /tmp/tcp-over-ipv4.bpf
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000006 },
{ 0x06,  0,  0, 0xffffffff },
{ 0x06,  0,  0, 0000000000 },

Seda teksti saab kopeerida tüübi struktuuri määratlemisse struct sock_filter, nagu me käesoleva jaotise alguses tegime.

Linuxi ja netsniff-ng laiendused

Lisaks standardsetele BPF käskudele toetavad Linux ja tools/bpf/bpf_asm ka mittestandardset komplekti. Peamiselt teenivad käskud nõutud struktuuri laagri väljadele pääsemiseks struct sk_buff, mis kirjeldab võrkpakkide struktuuri tuumas. Samas on ka teise tüübi abikäskud, näiteks ldw cpu laadib registrisse A tuuma funktsiooni käitamise tulemuse raw_smp_processor_id().(Uues BPF versioonis on neid mittestandardseid laiendusi laiendatud programmide paaride ja kernel helpers kogumi kaudu mälule, struktuuridele ning sündmuste genereerimisele.) Siin on huvitav näide filterist, kus kopeerime kasutajaruumi ainult pakettide päised, kasutades laiendust poff, koormuse offset:

ld poff
ret a

BPF laiendusi ei saa kasutada tcpdump, aga see on hea põhjus tutvuda utiliitide paketiga netsniff-ng, mis sisaldab, muu hulgas, ka täiustatud programmi netsniff-ng, mis, peale BPF-ga filtreerimise, sisaldab ka efektiivset liikluse genereerijat ja sageli paremat BPF assemblerit nimega tools/bpf/bpf_asmbpfc. Paketis on üsna põhjalik dokumentatsioon, vt ka artikli lõpus olevad lingid.Nii et me oskame juba kirjutada BPF programme mistahes keerukusega ja oleme valmis vaatama uusi näiteid, esimene neist on tehnoloogia seccomp, mis võimaldab BPF filterite kaudu hallata mitmeid ja süsteemikutsungite argumendi komplekti, mis on selle protsessi ja tema järeltulijate jaoks kättevõimalik.

seccomp

Esimene seccomp versioon lisati tuuma 2005. aastal ning see ei olnud suurt populaarsust saavutanud, kuna pakkus ainult üht võimalust — piirata mitmeid süsteemikutsungite varustust, mis sellele protsessile on kättevõimalik:

sigreturn lugema, kirjutama, exit ja , kuid protsess, mis reegleid rikkus, surmatiSIGKILL SIGKILL. Kuid 2012. aastal lisati seccompi võimalus kasutada BPF filtreid, mis võimaldavad määrata arvukalt lubatud süsteemikutseid ning isegi kontrollida nende argumente. (Huvitav on, et Chrome oli üks esimesi, kes seda funktsionaalsust kasutas, ja praegu töötavad Chrome'i inimesed välja KRSI mehhanismi, mis põhineb uuemal BPF versioonil ja võimaldab kohandada Linuxi turvamooduleid.) Lisadokumendi viidatud leidub artikli lõpus.

Oluline on üles märkida, et Habril on juba olnud artikleid seccompi kasutamise kohta, võib-olla tahab keegi neid lugeda enne (või selle asemel), kui liigub edasi järgmistele alajaotustele. Artiklis Konteinerid ja turvalisus: seccomp toodud näited seccompi kasutamisest nii 2007. aasta versiooni kui ka BPF kasutamise versiooni kohta (filtrid genereeritakse libseccompi abil), räägitakse seccompi seosest Dockeriga ning antakse palju kasulikke viiteid. Artiklis Isoleerime süsteemid systemd-ga või "sul ei ole Dockerit selle jaoks vaja!" räägitakse eelkõige sellest, kuidas lisada süsteemikutsed mustadesse või valgetesse nimekirjadesse systemd halduses oleva süsteemi jaoks.

Edasi vaatame, kuidas kirjutada ja laadida filtreid seccomp puhta C keele abil ja libseccompi raamatukogust välja. libseccomp ja millised on iga variandi plussid ja miinused; lõpuks vaatame, kuidas seccompi kasutab programm. strace.

Kirjutame ja laadime seccompi filtreid

Me oskame juba kirjutada BPF programme, seega vaatame esmalt seccomp'i programmiliidest. Filtri saab seadistada protsessi tasemel, kus kõik lasteprotsessid pärivad piirangud. See toimub süsteemikutsungi abil seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

kus &filter — see on viide juba tuttavale struktuurile struct sock_fprog, st BPF programmile.

Kuidas erinevad seccompi programmid soketiprogrammidest? Edastatava konteksti poolest. Sokettide puhul edastati meile mäluala, mis sisaldas paketti, kuid seccompi puhul edastatakse meile struktuur tüübiga

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

Siin nr — see on käivitatava süsteemikutse number, arch — praegune arhitektuur (sellest allpool), args — kuni kuue süsteemikutsesse kuuluva argumendiga, ja instruction_pointer — see on viide kasutaja ruumis entsüklilise käsu jaoks, mis tegi selle süsteemikõne. Seega peame näiteks süsteemikõne numbri registreerimiseks ütlema A me peame ütlema

ldw [0]

Seccomp programmide jaoks on olemas ka teisi eripära, näiteks on juurdepääs kontekstile võimalik ainult 32-bitise eraldatuse korral ja ei saa laadida poole sõna või bait — filtri laadimise katse ldh [0] süsteemikõne seccomp tagastab EINVAL. Laadimise filtrite kontrolli teostab funktsioon seccomp_check_filter() kernis. (Naljakana, algses commit'is, mis lisas seccomp funktsionaalsuse, unustati sellele funktsioonile anda loa kasutada instruktsiooni mod (jääk) ja nüüd ei ole see seccomp BPF programmidele saadaval, kuna selle lisamine rikub ABI.)

Põhimõtteliselt teame juba kõike, et kirjutada ja lugeda seccomp programme. Tavaliselt on programmi loogika üles ehitatud nagu süsteemikõnede must nimekiri või valge nimekiri, näiteks programm

ld [0]
jeq #304, bad
jeq #176, bad
jeq #239, bad
jeq #279, bad
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
bad: ret #0

kontrollib musta nimekirja neljast süsteemikõnest numbritega 304, 176, 239, 279. Millised need süsteemikõned on? Me ei saa täpselt öelda, kuna me ei tea, millise arhitektuuri jaoks programm kirjutati. Seetõttu peavad seccomp autorid pakuvad kõiki programme alustama arhitektuuri kontrollimisega (praegune arhitektuur on kontekstis välja toodud valdkonnas arch struktuurid struct seccomp_data). Arhitektuuri kontrollimisega võiks näite algus välja näha nagu:

ld [4]
jne #0xc000003e, bad_arch ; SCMP_ARCH_X86_64

ja siis saaksime meie süsteemikõnede numbrid kindlad väärtused.

Kirjutame ja laadime seccomp filtreid kasutades `libseccomp`

Filtide kirjutamine masinkoodina või BPF assembleri jaoks võimaldab täielikku kontrolli tulemuse üle, kuid samas on mõnikord eelistatavam omada kantavat ja/või loetavat koodi. Sellega aitab meil raamatukogu libseccomp, mis pakub standardset liidest mustade või valgete filtrite kirjutamiseks.

Kirjutame näiteks programmi, mis käivitab kasutaja valitud binaarfaili, seadistades eelnevalt musta nimekirja süsteemikõnedest üles nimetatud artiklist (programm on lihtsustatud parema loetavuse nimel, täielikku varianti saab leida siit):

#include <seccomp.h>
#include <unistd.h>
#include <err.h>

static int sys_numbers[] = {
        __NR_mount,
        __NR_umount2,
       // ... еще 40 системных вызовов ...
        __NR_vmsplice,
        __NR_perf_event_open,
};

int main(int argc, char **argv)
{
        scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);

        for (size_t i = 0; i < sizeof(sys_numbers)/sizeof(sys_numbers[0]); i++)
                seccomp_rule_add(ctx, SCMP_ACT_TRAP, sys_numbers[i], 0);

        seccomp_load(ctx);

        execvp(argv[1], &argv[1]);
        err(1, "execlp: %s", argv[1]);
}

Alguses defineerime massiivi sys_numbers üle 40 süsteemikõne numbri blokeerimiseks. Siis initsialiseerime konteksti ctx ja räägime teegile, et soovime lubada (SCMP_ACT_ALLOW) kõiki süsteemi kõnesid vaikimisi (mustade nimekirjade koostamine on lihtsam). Seejärel lisame ükshaaval kõik süsteemi kõned musta nimekirja. Vastuseks mustal nimekirjal olevale süsteemi kõnele küsime SCMP_ACT_TRAP, sel juhul saadab seccomp protsessile signaali SIGSYS kirjeldusega, milline süsteemi kõne reegleid rikkus. Lõpuks laadime programmi kärku kasutades seccomp_load, mis kompileerib programmi ja ühendab selle protsessiga süsteemi kõne abil seccomp(2).

Eduka kompileerimise jaoks tuleb programm lingida teegiga libseccomp, näiteks:

cc -std=c17 -Wall -Wextra -c -o seccomp_lib.o seccomp_lib.c
cc -o seccomp_lib seccomp_lib.o -lseccomp

Näide edukast käivitamisest:

$ .\/seccomp_lib echo ok
ok

Näide blokeeritud süsteemi kõnest:

$ sudo .\/seccomp_lib mount -t bpf bpf \/tmp
Halb süsteemi kõne

Kasutame strace, et teada saada rohkem:

$ sudo strace -e seccomp .\/seccomp_lib mount -t bpf bpf \/tmp
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=50, filter=0x55d8e78428e0}) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0xboobdeadbeef, si_syscall=__NR_mount, si_arch=AUDIT_ARCH_X86_64} ---
+++ SIGSYS poolt tapetud (mälukogumine) +++
Halb süsteemi kõne

kust saame teada, et programm lõpetati keelatud süsteemi kõne kasutamise tõttu mount(2).

Kokkuvõttes oleme kirjutanud filtri kasutades teeki libseccomp, mahtudes mittetüüpilisse koodi nelja rida. Ülaltoodud näites võib süsteemi kõnede arvul olla oluline mõju täitmise ajale, kuna kontrollimine on lihtsalt loendite võrdlemine. Optimeerimiseks on hiljuti libseccompi lisatud plaaster, mis lisab toetuse filtri atribuudile SCMP_FLTATR_CTL_OPTIMIZE. Kui seadistate selle atribuudiks 2, muudetakse filter binaarse otsingu programmina.

Kui soovite näha, kuidas töötavad binaarse otsinguga filtrid, vaadake lihtsat skripti, mis genereerib selliseid programmi assembler BPF süsteemi kõnede numbrite kogumi põhjal, näiteks:

$ echo 1 3 6 8 13 | .\/generate_bin_search_bpf.py
ld [0]
jeq #6, bad
jgt #6, check8
jeq #1, bad
jeq #3, bad
ret #0x7fff0000
check8:
jeq #8, bad
jeq #13, bad
ret #0x7fff0000
bad: ret #0

Ei saa kirjutada midagi oluliselt kiiremat, kuna BPF programmid ei saa teha hargnemisi (me ei saa teha näiteks jmp A või jmp [label+X]) ja seetõttu on kõik hargnemised staatilised.

seccomp ja strace

Kõik teavad utiliiti strace — asendamatu tööriist protsesside käitumise uurimisel Linuxis. Kuid paljud on ka kuulnud jõudlusprobleemid selle tööriista kasutamise korral. Asi on selles, et strace on rakendatud ptrace(2), kuid selles mehhanismis ei saa me määrata, millistel täpselt süsteemi kutsungitel me protsessi peame peatama, st näiteks käsud

$ time strace du /usr/share/ >/dev/null 2>&1

real    0m3.081s
user    0m0.531s
sys     0m2.073s

$ time strace -e open du /usr/share/ >/dev/null 2>&1

real    0m2.404s
user    0m0.193s
sys     0m1.800s

töötavad enam-vähem sama ajaga, kuigi teises variandis tahame jälgida ainult ühte süsteemi kutsungit.

Uus valik --seccomp-bpf, lisatud strace versioonis 5.3, võimaldab protsessi kiirusel korduvalt suureneda ja ühe süsteemi kutsungi jälgimise käivitamise aeg on nüüd võrreldav tavalise käivitamise ajaga:

$ time strace --seccomp-bpf -e open du /usr/share/ >/dev/null 2>&1

real    0m0.148s
user    0m0.017s
sys     0m0.131s

$ time du /usr/share/ >/dev/null 2>&1

real    0m0.140s
user    0m0.024s
sys     0m0.116s

(Siin on loomulikult väike petmine, et me ei jälgi selle käsu peamist süsteemi kutsungit. Kui me jälgiksime näiteks newfsstat, siis strace peaks töötama sama aeglaselt kui ilma --seccomp-bpf.)

Kuidas see valik toimib? Ilma selleta strace ühendub protsessiga ja käivitab selle PTRACE_SYSCALL. Kui hallatav protsess käivitab (mille tahes) süsteemi kutsungi, antakse juhtimine strace, mis vaatab süsteemi kutsungi argumente ja käivitab selle PTRACE_SYSCALL. Mõne aja pärast lõpetab protsess süsteemi kutsungi ja väljudes antakse juhtimine jälle strace, mis vaatab tagastatud väärtusi ja käivitab protsessi PTRACE_SYSCALL, jne.

Kuid seccompi abil saab seda protsessi optimeerida just nii, nagu me soovime. Nimelt, kui tahame vaadata ainult süsteemi kutsungit X, saame kirjutada BPF filtri, mis X tagastab väärtuse SECCOMP_RET_TRACE, ja mittesoovitavate kutsungite jaoks — SECCOMP_RET_ALLOW:

ld [0]
jneq #X, ignore
trace: ret #0x7ff00000
ignore: ret #0x7fff0000

Sellisel juhul strace käivitab alguses protsessi kui PTRACE_CONT, iga süsteemi kutsungi korral töötab meie filter, kui süsteemi kutsung ei X, siis protsess jätkab tööd, kuid kui see X, siis seccomp edastab juhtimise strace, mis vaatab argumente ja käivitab protsessi nagu PTRACE_SYSCALL (kuna seccompis ei ole võimalik programmi käivitada süsteemi kutsungi väljumisel). Kui süsteemi kutsung naaseb, strace käivitab protsessi uuesti PTRACE_CONT ja ootab uusi teateid seccompilt.

valiku kasutamisel --seccomp-bpf on kaks piirangut. Esiteks ei saa ühendada juba toimivale protsessile (valik -p programmide strace), kuna seda ei toetata seccomp. Teiseks, puudub võimalus ei vaadata alaprotsesse, kuna seccomp filtrid päranduvad kõigile alaprotsessidele ilma võimaluseta seda välja lülitada.

Veidi rohkem üksikasju selle kohta, kuidas täpselt strace töötab seccomp saab teada meie viimasest aruandest . Meie jaoks on kõige huvitavam fakt see, et klassikaline BPF seccomp kujul leiab endiselt rakendust.Liigume nüüd tagasi võrkude maailma.

`xt_bpf`

Taust: ammu, 2007. aastal, murdis tuuma

xt_u32 on lisatud moodul netfilter jaoks. See kirjutati sarnases stiilis nagu veelgi vana liikluse klassifikaator cls_u32 ja võimaldas kirjutada suvalisi binaarreegleid iptables'i abil, kasutades järgmisi lihtsaid operatsioone: laadida 32 bitti paketist ja teha neile rida aritmeetilisi operatsioone. Näiteks, sudo iptables -A INPUT -m u32 --u32 "6&0xFF=1" -j LOG --log-prefix "seen-by-xt_u32"

Laadib 32 bitti IP-pealkirjast, alustades nihkest 6, ja rakendab neile maske

0xFF (võtab alumise baidi). See on IP-pealkirja piirkond ja me võrdleme seda 1-ga (ICMP). Ühes reeglites saab koos kombineerida palju kontrolle ning samuti saab teha operatsiooni — liikuda X bitti paremale. Näiteks reegel protocol iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4=0x29" @ kontrollib, kas TCP järjestusnumber on

. Ma ei hakka sisse minema rohkem üksikasjadesse, kuna on juba selge, et käsitsi selliste reeglite kirjutamine ei ole just mugav. Artiklis

BPF — unustatud baitkood 0x29, on mitmeid linke näidiste ja reeglite genereerimise kohta . Vaata ka lingid artikli lõpust.Alates 2013. aastast saab mooduli asemel kasutada BPF-põhist moodulit. netfilter jaoks. See kirjutati sarnases stiilis nagu veelgi vana liikluse klassifikaatorKuni siia lugenud, peaks põhimõte olema selge: käivitada BPF baitkood iptables'i reeglite puhul. Uue reegli loomine on võimalik näiteks nii:

iptables -A INPUT -m bpf --bytecode -j LOG netfilter jaoks. See kirjutati sarnases stiilis nagu veelgi vana liikluse klassifikaator saab kasutada BPF-põhist moodulit xt_bpfon assemblatori väljundformaat bpf_asm

vaikimisi, näiteks,

siin $ cat /tmp/test.bpf ldb [9] jneq #17, ignore ret #1 ignore: ret #0$ bpf_asm /tmp/test.bpf 4,48 0 0 9,21 0 1 17,6 0 0 1,6 0 0 0,# iptables -A INPUT -m bpf --bytecode "$(bpf_asm /tmp/test.bpf)" -j LOG Selles näites filtreerime kõiki UDP pakette. BPF programmi kontekst moodulis , viitab loomulikult paketi andmetele, iptables'i puhul — IPv4 pealkirja algusele. BPF programmi tagastatav väärtus boolean

tähendab, et pakett ei vastanud.

. xt_bpf. ., kus false .

Selge, et moodul xt_bpf toetab keerukamaid filtre kui ülaltoodud näites. Vaatame tõelisi näiteid ettevõttelt Cloudflare. Kuni hiljutise ajani kasutasid nad moodulit xt_bpf DDoS rünnakute kaitseks. Artiklis Tutvustame BPF tööriistu räägivad nad, kuidas (ja miks) nad genereerivad BPF filtreid ja publitseerivad linke tööriistade komplektile selliste filtrite loomise jaoks. Näiteks tööriista abil bpfgen võib luua BPF programmi, mis sobitab DNS-päringu nime habr.com:

$ ./bpfgen --assembly dns -- habr.com
ldx 4*([0]&0xf)
ld #20
add x
tax

lb_0:
    ld [x + 0]
    jneq #0x04686162, lb_1
    ld [x + 4]
    jneq #0x7203636f, lb_1
    ldh [x + 8]
    jneq #0x6d00, lb_1
    ret #65535

lb_1:
    ret #0

Programmis laadime me kõigepealt registrisse X stringi alguse aadressi x04habrx03comx00 UDP-datagrammi sees ja seejärel kontrollime päringut: 0x04686162 "x04hab" jne.

Hiljem avaldas Cloudflare p0f kompilaatori koodi -> BPF. Artiklis Tutvustame p0f BPF kompilaatorit räägivad nad, mis on p0f ja kuidas muuta p0f allkirju BPF-iks:

$ ./bpfgen p0f -- 4:64:0:0:*,0::ack+:0
39,0 0 0 0,48 0 0 8,37 35 0 64,37 0 34 29,48 0 0 0,
84 0 0 15,21 0 31 5,48 0 0 9,21 0 29 6,40 0 0 6,
...

Praegu ei kasuta Cloudflare enam xt_bpf, kuna nad on kolinud XDP-le — üks variant uut BPF versiooni kasutada, vt. L4Drop: XDP DDoS leevendused.

`cls_bpf`

Viimane klassikalise BPF näide tuumas on klassifikaator cls_bpf Linuxi liikluse kontrollimise alamsüsteemi jaoks, mis lisati Linuxi 2013. aasta lõpus ja asendas kontseptuaalselt vana ja võimaldas kirjutada suvalisi binaarreegleid iptables'i abil, kasutades järgmisi lihtsaid operatsioone: laadida 32 bitti paketist ja teha neile rida aritmeetilisi operatsioone. Näiteks,.

Me ei kavatse praegu seda tööd kirjeldada cls_bpf, kuna klassikalise BPF-i tundmise seisukohalt ei anna see meile midagi — oleme juba tuttavad kogu funktsionaalsusega. Lisaks, järgnevates artiklites, mis käsitlevad laiendatud BPF-i, kohtume me selle klassifikaatoriga veel korduvalt.

Veel üks põhjus, miks mitte rääkida klassikalise BPF-i kasutamisest on see, et võrreldes laiendatud BPF-iga on selle puhul rakendatavuse ulatus oluliselt kitsenenud: klassikalised programmid ei saa muuta pakettide sisu ja ei saa salvestada olekut kutsungite vahel. cls_bpf Nii et on aeg hüvasti jätta klassikalisest BPF-ist ja vaadata tulevikku.

Hüvasti klassikalise BPF-iga

Hüvasti klassikaline BPF

Oleme vaadanud, kuidas 1990. aastate alguses välja töötatud BPF-tehnoloogia on edukalt kestnud veerand sajandit ja leidnud uusi rakendusi. Kuid sarnaselt siirdega virnastatud masinatelt RISC-ile, mis andis tõuke klassikalise BPF-i väljatöötamiseks, leidis 2000ndatel aset üleminek 32-bitiselt 64-bitisele arhitektuurile, mistõttu klassikaline BPF hakkas ajale jalgu jääma. Lisaks on klassikalise BPF-i võimalused tugevalt piiratud ning lisaks vananenud arhitektuurile puudub meil võimalus salvestada olekut BPF-programmide vahel, ei ole võimalik otseselt suhelda kasutajaga ega suhtelda tuumaga, välja arvatud piiratud arvu struktuuri väljade lugemine. sk_buff ja käivitada lihtsamaid abifunktsioone, ei saa pakettide sisu muuta ega neid suunata.

Tegelikult on praegu Linuxis klassikalisest BPF-ist jäänud järgi ainult API-liides, samas kui kogu klassikalised programmid, olgu need siis socket-filterid või seccomp-filterid, tõlgitakse automaatselt uude vormingusse, Extended BPF. (Kuidas seda täpselt tehakse, kirjeldame järgmisel artiklil.)

Uuele arhitektuurile üleminek algas 2013. aastal, kui Aleksei Starovoitov pakkus välja BPF-i värskendamise skeemi. 2014. aastal hakkasid vastavad plaastrid ilmuma tuumas. Nii palju tean, et algselt oli plaanis vaid optimeerida arhitektuuri ja JIT-kompileerijat efektiivsemaks tööks 64-bitistel masinatel, kuid selle asemel andsid need optimeerimised alguse uuele peatükile Linuxi arenduses.

Uurivad artiklid selles sarjas räägivad uue tehnoloogia arhitektuurist ja rakendustest, mis algselt oli tuntud kui internal BPF, seejärel extended BPF ning nüüd lihtsalt BPF.

Viidatud lingid

Steven McCanne ja Van Jacobson, "The BSD Packet Filter: Uus arhitektuur kasutaja tasemel pakettide püüdmiseks", https://www.tcpdump.org/papers/bpf-usenix93.pdf
Steven McCanne, "libpcap: Arhitektuur ja optimeerimisvägitegu pakettide püüdmiseks", https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
tcpdump, libpcap: https://www.tcpdump.org/
IPtable U32 Match Tutorial.
BPF — unustatud baitkood: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
BPF Tööriista tutvustus: https://blog.cloudflare.com/introducing-the-bpf-tools/
bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
Seccomp ülevaade: https://lwn.net/Articles/656307/
https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
habr: Konteinerid ja turvalisus: seccomp
habr: Isolatsioonisüsteemid systemd abil või "sulle ei ole vaja Dockerit selleks!"
Paul Chaignon, "strace —seccomp-bpf: pilguheit kapoti alla", https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
netsniff-ng: http://netsniff-ng.org/