Книга за следење на BPF за Linux

Здраво, жители на Хабро! Виртуелната машина BPF е една од најважните компоненти на кернелот Линукс. Неговата правилна употреба ќе им овозможи на системските инженери да најдат грешки и да ги решат дури и најсложените проблеми. Ќе научите како да пишувате програми што го следат и менуваат однесувањето на кернелот, како безбедно да имплементирате код за следење на настани во кернелот и многу повеќе. Дејвид Калавера и Лоренцо Фонтана ќе ви помогнат да ја отклучите моќта на BPF. Проширете го вашето знаење за оптимизација на перформанси, вмрежување, безбедност. - Користете BPF за следење и менување на однесувањето на кернелот Линукс. - Инјектирајте код за безбедно следење на настаните на кернелот без да мора повторно да го компајлирате кернелот или да го рестартирате системот. — Користете пригодни примери на код во C, Go или Python. - Преземете ја контролата со поседување на животниот циклус на програмата BPF.

Безбедност на кернелот на Linux, неговите карактеристики и Seccomp

BPF обезбедува моќен начин за проширување на кернелот без да се жртвува стабилноста, безбедноста или брзината. Поради оваа причина, развивачите на кернелот сметаа дека би било добра идеја да ја искористат неговата разновидност за да ја подобрат изолацијата на процесите во Seccomp со имплементирање на филтри Seccomp поддржани од програмите BPF, исто така познати како Seccomp BPF. Во ова поглавје ќе објасниме што е Seccomp и како се користи. Потоа ќе научите како да пишувате Seccomp филтри користејќи BPF програми. После тоа, ќе ги разгледаме вградените куки BPF кои се вклучени во кернелот за безбедносните модули на Linux.

Линукс безбедносните модули (LSM) се рамка која обезбедува збир на функции што може да се користат за имплементација на различни безбедносни модели на стандардизиран начин. LSM може да се користи директно во дрвото на изворот на јадрото, како што се Apparmor, SELinux и Tomoyo.

Да почнеме со дискусија за можностите на Linux.

Способности

Суштината на можностите на Linux е дека треба да му дадете дозвола на непривилегиран процес за извршување на одредена задача, но без користење на suid за таа цел, или на друг начин да го направите процесот привилегиран, намалувајќи ја можноста за напад и дозволувајќи му на процесот да извршува одредени задачи. На пример, ако вашата апликација треба да отвори привилегирана порта, да речеме 80, наместо да го извршува процесот како root, можете едноставно да и ја дадете способноста CAP_NET_BIND_SERVICE.

Размислете за Go програма со име main.go:

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

Оваа програма опслужува HTTP сервер на портата 80 (ова е привилегирана порта). Обично го работиме веднаш по компилацијата:

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

Меѓутоа, бидејќи не даваме права за root, овој код ќе фрли грешка при врзувањето на портата:

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

capsh (менаџер на школка) е алатка која работи на школка со специфичен сет на способности.

Во овој случај, како што веќе беше споменато, наместо да давате целосни права за root, можете да овозможите привилегирано поврзување на портата со обезбедување на способноста cap_net_bind_service заедно со сè друго што е веќе во програмата. За да го направите ова, можеме да ја приложиме нашата програма во 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"

Да го разбереме овој тим малку.

• capsh - користете capsh како школка.
• —caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' - бидејќи треба да го смениме корисникот (не сакаме да работиме како root), ќе наведеме cap_net_bind_service и способност всушност да го смениме корисничкиот ID од root to nobody, имено cap_setuid и cap_setgid.
• —keep=1 — сакаме да ги задржиме инсталираните можности при префрлање од root сметката.
• —user=“никој“ — крајниот корисник кој ја води програмата ќе биде никој.
• —addamb=cap_net_bind_service — поставете го бришењето на поврзаните способности по префрлањето од root режимот.
• - -c "./capabilities" - само стартувајте ја програмата.

Поврзаните способности се посебен вид на способности кои се наследени од детските програми кога тековната програма ги извршува со помош на execve(). Може да се наследат само способности што е дозволено да се поврзат, или со други зборови, како способности на околината.

Веројатно се прашувате што значи +eip откако ќе ја наведете способноста во опцијата --caps. Овие знаменца се користат за да се утврди дека способноста:

-мора да се активира (p);

- достапни за употреба (д);

-може да се наследи со дете процеси (i).

Бидејќи сакаме да користиме cap_net_bind_service, треба да го направиме ова со знамето e. Потоа ќе ја започнеме школка во командата. Ова ќе ги активира можностите бинарно и треба да го означиме со знаменцето i. Конечно, сакаме функцијата да биде овозможена (ова го направивме без промена на UID) со стр. Изгледа како cap_net_bind_service+eip.

Можете да го проверите резултатот користејќи ss. Ајде малку да го скратиме излезот за да се вклопи на страницата, но ќе ја прикаже поврзаната порта и корисничкиот ID освен 0, во овој случај 65:

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

Во овој пример користевме capsh, но можете да напишете школка користејќи libcap. За повеќе информации, видете man 3 libcap.

Кога пишувате програми, доста често развивачот однапред не ги знае сите карактеристики што ѝ се потребни на програмата за време на извршувањето; Покрај тоа, овие карактеристики може да се променат во новите верзии.

За подобро да ги разбереме можностите на нашата програма, можеме да ја земеме алатката способна за BCC, која ја поставува kprobe за функцијата на кернелот 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

Можеме да го постигнеме истото со користење на bpftrace со еднослојна kprobe во функцијата на кернелот 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

Ова ќе излезе нешто слично на следново ако способностите на нашата програма се овозможени по 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

Петтата колона се способностите што му се потребни на процесот, и бидејќи овој излез вклучува неревизорски настани, ги гледаме сите неревизорски проверки и на крајот потребната способност со знаменцето за ревизија (последно во излезот) поставено на 1. Способност. еден што нè интересира е CAP_NET_BIND_SERVICE, тој е дефиниран како константа во изворниот код на кернелот во датотеката include/uapi/linux/ability.h со идентификатор 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">

Можностите често се овозможени за време на извршувањето за контејнерите како што се runC или Docker за да им се овозможи да работат во непривилегиран режим, но им се дозволени само можностите потребни за извршување на повеќето апликации. Кога апликацијата бара одредени способности, Docker може да ги обезбеди користејќи --cap-add:

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

Оваа команда ќе му даде на контејнерот способност CAP_NET_ADMIN, дозволувајќи му да конфигурира мрежна врска за да го додаде dummy0 интерфејсот.

Следниот дел покажува како да ги користиме функциите како филтрирање, но со користење на различна техника која ни овозможува програмски да ги имплементираме нашите сопствени филтри.

Seccomp

Seccomp е кратенка за Secure Computing и е безбедносен слој имплементиран во кернелот Linux што им овозможува на програмерите да филтрираат одредени системски повици. Иако Seccomp е споредлив по способности со Linux, неговата способност да управува со одредени системски повици го прави многу пофлексибилен во споредба со нив.

Функциите на Seccomp и Linux не се исклучуваат меѓусебно и често се користат заедно за да имаат корист од двата пристапи. На пример, можеби ќе сакате да му ја дадете на еден процес способноста CAP_NET_ADMIN, но да не му дозволите да прифаќа приклучоци за приклучоци, блокирајќи ги системските повици прифаќај и прифаќај4.

Методот на филтрирање Seccomp се заснова на BPF филтри кои работат во режимот SECCOMP_MODE_FILTER, а филтрирањето на системскиот повик се врши на ист начин како и за пакетите.

Seccomp филтрите се вчитуваат со prctl преку операцијата PR_SET_SECCOMP. Овие филтри имаат форма на програма BPF која се извршува за секој пакет Seccomp претставен со структурата seccomp_data. Оваа структура содржи референтна архитектура, покажувач кон инструкциите на процесорот во моментот на системскиот повик и максимум шест аргументи за системски повик, изразени како uint64.

Вака изгледа структурата seccomp_data од изворниот код на кернелот во датотеката linux/seccomp.h:

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

Како што можете да видите од оваа структура, можеме да филтрираме според системскиот повик, неговите аргументи или комбинација од двете.

По добивањето на секој пакет Seccomp, филтерот мора да изврши обработка за да донесе конечна одлука и да му каже на кернелот што да прави следно. Конечната одлука се изразува со една од повратните вредности (шифри за статус).

- SECCOMP_RET_KILL_PROCESS - го убива целиот процес веднаш по филтрирањето на системски повик што не е извршен поради тоа.

- SECCOMP_RET_KILL_THREAD - ја прекинува тековната нишка веднаш по филтрирањето на системски повик што не е извршен поради тоа.

— SECCOMP_RET_KILL — алијас за SECCOMP_RET_KILL_THREAD, оставен за компатибилност наназад.

- SECCOMP_RET_TRAP - системскиот повик е забранет, а сигналот SIGSYS (лош системски повик) се испраќа до задачата што го повикува.

- SECCOMP_RET_ERRNO - Системскиот повик не е извршен, а дел од повратната вредност на филтерот SECCOMP_RET_DATA се пренесува на корисничкиот простор како вредност за грешка. Во зависност од причината за грешката, се враќаат различни вредности за грешка. Списокот со броеви на грешки е даден во следниот дел.

- SECCOMP_RET_TRACE - Се користи за известување на трагачот на ptrace користејќи - PTRACE_O_TRACESECCOMP за пресретнување кога се извршува системски повик за да се види и контролира тој процес. Ако трасерот не е поврзан, се враќа грешка, errno се поставува на -ENOSYS и системскиот повик не се извршува.

- SECCOMP_RET_LOG - системскиот повик е решен и евидентиран.

- SECCOMP_RET_ALLOW - системскиот повик е едноставно дозволен.

ptrace е системски повик за имплементација на механизми за следење во процес наречен tracee, со можност за следење и контрола на извршувањето на процесот. Програмата за следење може ефективно да влијае на извршувањето и да ги менува мемориските регистри на трага. Во контекстот Seccomp, ptrace се користи кога се активира од статусната шифра SECCOMP_RET_TRACE, така што трасерот може да го спречи извршувањето на системскиот повик и да ја имплементира сопствената логика.

Seccomp грешки

Од време на време, додека работите со Seccomp, ќе наидете на различни грешки, кои се идентификуваат со повратна вредност од типот SECCOMP_RET_ERRNO. За да пријавите грешка, системскиот повик seccomp ќе врати -1 наместо 0.

Следниве грешки се можни:

- EACCESS - На повикувачот не му е дозволено да воспоставува системски повик. Ова обично се случува затоа што нема CAP_SYS_ADMIN привилегии или no_new_privs не е поставено со prctl (ќе зборуваме за ова подоцна);

— EFAULT — донесените аргументи (args во структурата seccomp_data) немаат валидна адреса;

— EINVAL — овде може да има четири причини:

-бараната операција е непозната или не е поддржана од кернелот во тековната конфигурација;

-наведените знаменца не важат за бараната операција;

-операцијата вклучува BPF_ABS, но има проблеми со наведеното поместување, кое може да ја надмине големината на структурата seccomp_data;

-бројот на инструкции предадени на филтерот го надминува максимумот;

— ENOMEM — нема доволно меморија за извршување на програмата;

- EOPNOTSUPP - операцијата покажа дека со SECCOMP_GET_ACTION_AVAIL дејството било достапно, но кернелот не поддржува враќање во аргументи;

— ESRCH — се појави проблем при синхронизирање на друг пренос;

- ENOSYS - Нема прикачен трагач за дејството SECCOMP_RET_TRACE.

prctl е системски повик кој дозволува програма за кориснички простор да манипулира (поставува и добива) специфични аспекти на процесот, како што се широчината на бајти, имињата на нишките, безбедниот режим на пресметување (Seccomp), привилегиите, настаните на Perf итн.

Seccomp можеби ви изгледа како технологија за песок, но не е. Seccomp е алатка која им овозможува на корисниците да развијат механизам за песок. Сега да погледнеме како програмите за интеракција со корисници се креираат со помош на филтер повикан директно од системскиот повик Seccomp.

Пример за филтер BPF Seccomp

Овде ќе покажеме како да ги комбинираме двете дејства дискутирани претходно, имено:

— ќе напишеме Seccomp BPF програма, која ќе се користи како филтер со различни шифри за враќање во зависност од донесените одлуки;

— вчитајте го филтерот користејќи prctl.

Прво ви требаат заглавија од стандардната библиотека и кернелот на Linux:

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

Пред да се обидеме со овој пример, мора да се осигураме дека кернелот е компајлиран со CONFIG_SECCOMP и CONFIG_SECCOMP_FILTER поставен на y. На работна машина можете да го проверите ова вака:

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

Остатокот од кодот е функција од два дела install_filter. Првиот дел ја содржи нашата листа на инструкции за филтрирање BPF:

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

Инструкциите се поставени со користење на макроата BPF_STMT и BPF_JUMP дефинирани во датотеката linux/filter.h.
Ајде да поминеме низ упатствата.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) - системот се вчитува и се акумулира од BPF_LD во форма на зборот BPF_W, пакетните податоци се наоѓаат на фиксно поместување BPF_ABS.

- BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) - проверува со помош на BPF_JEQ дали вредноста на архитектурата во константата на акумулаторот BPF_K е еднаква на arch. Ако е така, прескокнува со поместување 0 на следната инструкција, инаку скока на поместување 3 (во овој случај) за да се фрли грешка бидејќи лакот не се совпаѓа.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) - Се вчитува и се акумулира од BPF_LD во форма на зборот BPF_W, што е системски повик број содржан во фиксното поместување на BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — го споредува бројот на системскиот повик со вредноста на променливата nr. Ако се еднакви, преминува на следната инструкција и го оневозможува системскиот повик, инаку дозволува системски повик со SECCOMP_RET_ALLOW.

- BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (грешка & SECCOMP_RET_DATA)) - ја прекинува програмата со BPF_RET и како резултат произведува грешка SECCOMP_RET_ERRNO со бројот од променливата err.

- BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) - ја прекинува програмата со BPF_RET и дозволува системскиот повик да се изврши со помош на SECCOMP_RET_ALLOW.

SECCOMP Е CBPF
Можеби се прашувате зошто се користи список со инструкции наместо компајлиран објект ELF или програма C составена од JIT.

Постојат две причини за ова.

• Прво, Seccomp користи cBPF (класичен BPF), а не eBPF, што значи: нема регистри, туку само акумулатор за складирање на последниот резултат од пресметката, како што може да се види во примерот.

• Второ, Seccomp прифаќа покажувач кон низа од BPF инструкции директно и ништо друго. Макроата што ги користевме едноставно помагаат да се специфицираат овие инструкции на начин погодно за програмери.

Ако ви треба повеќе помош за разбирање на овој состав, размислете за псевдокодот што го прави истото:

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

Откако ќе го дефинирате кодот на филтерот во структурата socket_filter, треба да дефинирате sock_fprog што го содржи кодот и пресметаната должина на филтерот. Оваа структура на податоци е потребна како аргумент за декларирање на процесот да работи подоцна:

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

Останува само една работа во функцијата install_filter - вчитајте ја самата програма! За да го направиме ова, користиме prctl, земајќи го PR_SET_SECCOMP како опција за да влеземе во режим на безбеден пресметување. Потоа му кажуваме на режимот да го вчита филтерот користејќи SECCOMP_MODE_FILTER, кој е содржан во променливата прог од типот sock_fprog:

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

Конечно, можеме да ја користиме нашата функција install_filter, но пред тоа треба да користиме prctl за да поставиме PR_SET_NO_NEW_PRIVS за тековното извршување и со тоа да ја избегнеме ситуацијата кога детските процеси добиваат повеќе привилегии од нивните родители. Со ова, можеме да ги направиме следните prctl повици во функцијата install_filter без да имаме права на root.

Сега можеме да ја повикаме функцијата install_filter. Ајде да ги блокираме сите системски повици за пишување поврзани со архитектурата X86-64 и едноставно да дадеме дозвола што ги блокира сите обиди. По инсталирањето на филтерот, продолжуваме со извршувањето користејќи го првиот аргумент:

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

Ајде да почнеме. За да ја компајлираме нашата програма, можеме да користиме или clang или gcc, во секој случај тоа е само компајлирање на датотеката main.c без посебни опции:

clang main.c -o filter-write

Како што е наведено, ги блокиравме сите записи во програмата. За да го тестирате ова, потребна ви е програма што дава нешто - ls изгледа како добар кандидат. Таа обично се однесува вака:

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

Прекрасно! Еве како изгледа користењето на нашата програма за обвивка: Едноставно ја пренесуваме програмата што сакаме да ја тестираме како прв аргумент:

./filter-write "ls -la"

Кога се извршува, оваа програма произведува целосно празен излез. Сепак, можеме да користиме strace за да видиме што се случува:

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

Резултатот од работата е значително скратен, но соодветниот дел од него покажува дека записите се блокирани со грешката EPERM - истата онаа што ја конфигуриравме. Ова значи дека програмата не емитува ништо бидејќи не може да пристапи до системскиот повик за запишување:

[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)

Сега разбирате како функционира Seccomp BPF и имате добра идеја за тоа што можете да направите со него. Но, зарем не би сакале да го постигнете истото со eBPF наместо со cBPF за да ја искористите неговата целосна моќ?

Кога размислуваат за програмите eBPF, повеќето луѓе мислат дека едноставно ги пишуваат и ги вчитуваат со администраторски привилегии. Иако оваа изјава е генерално вистинита, кернелот имплементира збир на механизми за заштита на објектите на eBPF на различни нивоа. Овие механизми се нарекуваат BPF LSM стапици.

BPF LSM стапици

За да обезбеди следење на системските настани независно од архитектурата, LSM го имплементира концептот на стапици. Повикот за кука е технички сличен на системскиот повик, но е системски независен и интегриран со инфраструктурата. LSM обезбедува нов концепт во кој слојот на апстракција може да помогне да се избегнат проблемите што се среќаваат кога се работи со системски повици на различни архитектури.

Во моментот на пишување, кернелот има седум куки поврзани со BPF програмите, а SELinux е единствениот вграден LSM што ги имплементира.

Изворниот код за замките се наоѓа во дрвото на јадрото во датотеката 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);

Секој од нив ќе биде повикан во различни фази на извршување:

— security_bpf — врши почетна проверка на извршените BPF системски повици;

- security_bpf_map - проверува кога кернелот враќа дескриптор на датотека за мапата;

- security_bpf_prog - проверува кога кернелот враќа дескриптор на датотека за програмата eBPF;

— security_bpf_map_alloc — проверува дали безбедносното поле во мапите BPF е иницијализирано;

- security_bpf_map_free - проверува дали безбедносното поле е исчистено во мапите на BPF;

— security_bpf_prog_alloc — проверува дали безбедносното поле е иницијализирано во BPF програмите;

- security_bpf_prog_free - проверува дали безбедносното поле е исчистено во програмите BPF.

Сега, гледајќи го сето ова, разбираме: идејата зад LSM BPF пресретнувачите е дека тие можат да обезбедат заштита на секој објект eBPF, осигурувајќи дека само оние со соодветни привилегии можат да вршат операции на картички и програми.

Краток преглед

Безбедноста не е нешто што можете да го имплементирате на еден единствен начин за се што сакате да заштитите. Важно е да можете да ги заштитите системите на различни нивоа и на различни начини. Верувале или не, најдобар начин да се обезбеди систем е да се организираат различни нивоа на заштита од различни позиции, така што намалувањето на безбедноста на едно ниво не дозволува пристап до целиот систем. Основните програмери направија одлична работа да ни дадат сет од различни слоеви и допирни точки. Се надеваме дека добро ви дадовме разбирање за тоа што се слоеви и како да ги користите програмите BPF за да работите со нив.

За авторите

Дејвид Калавера е CTO во Netlify. Тој работеше во поддршката на Docker и придонесе за развојот на алатките Runc, Go и BCC, како и други проекти со отворен код. Познат по неговата работа на проектите на Docker и развојот на екосистемот за приклучоци Docker. Дејвид е многу страстен за графиконите со пламен и секогаш бара да ги оптимизира перформансите.

Лоренцо Фонтана работи во тимот со отворен код во Sysdig, каде што првенствено е фокусиран на Falco, проект на Cloud Native Computing Foundation кој обезбедува безбедност на траење на контејнерот и откривање аномалија преку модул на јадрото и eBPF. Тој е страстен за дистрибуирани системи, софтверски дефинирани мрежи, кернелот Линукс и анализа на перформансите.

» Повеќе детали за книгата можете да најдете на веб-страница на издавачот
» Содржина
» Извадок

За Khabrozhiteley 25% попуст со користење на купон - Linux

По уплата на хартиената верзија на книгата ќе биде испратена електронска книга по е-пошта.

Извор: www.habr.com