Книга "BPF за наблюдение на Linux"

Здравейте жители на Хабро! BPF виртуалната машина е един от най-важните компоненти на ядрото на Linux. Правилното му използване ще позволи на системните инженери да откриват грешки и да решават дори най-сложните проблеми. Ще научите как да пишете програми, които наблюдават и променят поведението на ядрото, как безопасно да прилагате код за наблюдение на събития в ядрото и много повече. Дейвид Калавера и Лоренцо Фонтана ще ви помогнат да отключите силата на BPF. Разширете знанията си за оптимизация на производителността, работа в мрежа, сигурност. - Използвайте BPF за наблюдение и промяна на поведението на Linux ядрото. - Инжектирайте код за сигурно наблюдение на събитията в ядрото, без да се налага да компилирате ядрото отново или да рестартирате системата. — Използвайте удобни примери за код в C, Go или Python. - Поемете контрола, като притежавате жизнения цикъл на програмата BPF.

Сигурност на ядрото на Linux, неговите характеристики и Seccomp

BPF предоставя мощен начин за разширяване на ядрото, без да се жертва стабилност, сигурност или скорост. Поради тази причина разработчиците на ядрото решиха, че би било добра идея да използват неговата гъвкавост за подобряване на изолацията на процесите в Seccomp чрез прилагане на Seccomp филтри, поддържани от BPF програми, известни също като Seccomp BPF. В тази глава ще обясним какво е Seccomp и как се използва. След това ще научите как да пишете Seccomp филтри с помощта на BPF програми. След това ще разгледаме вградените BPF кукички, които са включени в ядрото за модули за сигурност на Linux.

Модулите за сигурност на 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 (shell manager) е инструмент, който управлява shell със специфичен набор от възможности.

В този случай, както вече беше споменато, вместо да предоставяте пълни 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 и възможността действително да променим потребителския идентификатор от root към никого, а именно cap_setuid и cap_setgid.
• —keep=1 — искаме да запазим инсталираните възможности при превключване от root акаунта.
• —user=“nobody” — крайният потребител, изпълняващ програмата, ще бъде никой.
• —addamb=cap_net_bind_service — задайте изчистването на свързаните възможности след превключване от root режим.
• - -c "./capabilities" - просто стартирайте програмата.

Свързаните възможности са специален вид възможности, които се наследяват от дъщерни програми, когато текущата програма ги изпълнява с помощта на execve(). Само способности, които могат да бъдат асоциирани, или с други думи, като възможности на средата, могат да бъдат наследени.

Вероятно се чудите какво означава +eip, след като посочите възможността в опцията --caps. Тези флагове се използват, за да се определи, че способността:

-трябва да се активира (p);

-достъпни за ползване (e);

-могат да бъдат наследени от дъщерни процеси (i).

Тъй като искаме да използваме cap_net_bind_service, трябва да направим това с флага e. След това ще стартираме обвивката в командата. Това ще изпълни бинарно възможностите и трябва да го маркираме с флага i. И накрая, искаме функцията да бъде активирана (направихме това, без да променяме UID) с p. Изглежда като cap_net_bind_service+eip.

Можете да проверите резултата с помощта на ss. Нека съкратим малко изхода, за да пасне на страницата, но той ще покаже свързания порт и потребителски идентификатор, различен от 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, но можете да напишете shell с помощта на 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, но да не му позволявате да приема връзки със сокет, блокирайки системните извиквания accept и accept4.

Методът на филтриране 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 (Bad System Call) се изпраща към задачата, която го извиква.

- SECCOMP_RET_ERRNO - Системното извикване не се изпълнява и част от върнатата стойност на филтъра SECCOMP_RET_DATA се предава на потребителското пространство като стойност errno. В зависимост от причината за грешката се връщат различни errno стойности. Списък с номера на грешки е даден в следващия раздел.

- SECCOMP_RET_TRACE - Използва се за уведомяване на ptrace tracer чрез - PTRACE_O_TRACESECCOMP за прихващане, когато се изпълнява системно повикване, за да видите и контролирате този процес. Ако инструментът за проследяване не е свързан, се връща грешка, errno е зададено на -ENOSYS и системното извикване не се изпълнява.

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

- SECCOMP_RET_ALLOW - системното повикване е просто разрешено.

ptrace е системно извикване за прилагане на механизми за проследяване в процес, наречен tracee, с възможност за наблюдение и контрол на изпълнението на процеса. Програмата за проследяване може ефективно да повлияе на изпълнението и да модифицира регистрите на паметта на tracee. В контекста на Seccomp ptrace се използва, когато се задейства от кода на състоянието SECCOMP_RET_TRACE, така че проследяващият може да предотврати изпълнението на системното извикване и да приложи своя собствена логика.

Seccomp грешки

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

Възможни са следните грешки:

- EACCESS - Повикващият няма право да извършва системно повикване. Това обикновено се случва, защото няма привилегии CAP_SYS_ADMIN или no_new_privs не е зададен чрез prctl (ще говорим за това по-късно);

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

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

-заявената операция е неизвестна или не се поддържа от ядрото в текущата конфигурация;

-посочените флагове не са валидни за заявената операция;

-операцията включва BPF_ABS, но има проблеми с посоченото отместване, което може да надвишава размера на структурата seccomp_data;

-броят на инструкциите, предадени на филтъра, надвишава максимума;

— ENOMEM — няма достатъчно памет за изпълнение на програмата;

- EOPNOTSUPP - операцията показва, че с SECCOMP_GET_ACTION_AVAIL действието е налично, но ядрото не поддържа връщане в аргументи;

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

- ENOSYS - Няма трасиране, прикачено към действието SECCOMP_RET_TRACE.

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

Seccomp може да ви изглежда като sandbox технология, но не е така. 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 (в този случай), за да изведе грешка, защото arch не съвпада.

- 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 | (error & 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 обект или JIT компилирана C програма.

Има две причини за това.

• Първо, 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, който се съдържа в променливата prog от тип 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 -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 програми за работа с тях.

За авторите

Дейвид Калавера е технически директор в Netlify. Работил е в поддръжката на Docker и е допринесъл за разработването на инструменти Runc, Go и BCC, както и други проекти с отворен код. Известен с работата си по проекти на Docker и разработването на екосистемата на плъгините на Docker. Дейвид е много запален по пламъчните графики и винаги се стреми да оптимизира производителността.

Лоренцо Фонтана работи в екипа с отворен код в Sysdig, където се фокусира основно върху Falco, проект на Cloud Native Computing Foundation, който осигурява сигурност на изпълнението на контейнера и откриване на аномалии чрез модул на ядрото и eBPF. Той е запален по разпределените системи, софтуерно дефинираните мрежи, ядрото на Linux и анализа на производителността.

» За повече информация относно книгата, моля посетете уебсайт на издателя
» Таблица на съдържанието
» Откъс

За Khabrozhiteli 25% отстъпка от купона - Linux

При заплащане на хартиената версия на книгата, на електронната поща се изпраща електронна книга.

Източник: www.habr.com