"Linux 모니터링을 위한 BPF" 책

안녕하세요, 카브로 주민 여러분! BPF 가상 머신은 Linux 커널의 가장 중요한 구성 요소 중 하나입니다. 이를 올바르게 사용하면 시스템 엔지니어가 결함을 찾아내고 가장 복잡한 문제도 해결할 수 있습니다. 커널의 동작을 모니터링하고 수정하는 프로그램을 작성하는 방법, 커널의 이벤트를 모니터링하는 코드를 안전하게 구현하는 방법 등을 배우게 됩니다. David Calavera와 Lorenzo Fontana는 BPF의 힘을 활용하는 데 도움을 줄 것입니다. 성능 최적화, 네트워킹, 보안에 대한 지식을 확장하세요. - BPF를 사용하여 Linux 커널의 동작을 모니터링하고 수정합니다. - 커널을 다시 컴파일하거나 시스템을 재부팅할 필요 없이 커널 이벤트를 안전하게 모니터링하는 코드를 삽입합니다. — C, Go 또는 Python에서 편리한 코드 예제를 사용합니다. - BPF 프로그램 수명주기를 소유하여 제어하세요.

Linux 커널 보안, 기능 및 Seccomp

BPF는 안정성, 보안 또는 속도를 희생하지 않고 커널을 확장할 수 있는 강력한 방법을 제공합니다. 이러한 이유로 커널 개발자는 Seccomp BPF라고도 알려진 BPF 프로그램에서 지원하는 Seccomp 필터를 구현하여 Seccomp의 프로세스 격리를 개선하기 위해 다양한 기능을 사용하는 것이 좋은 생각이라고 생각했습니다. 이 장에서는 Seccomp가 무엇이며 어떻게 사용되는지 설명합니다. 그런 다음 BPF 프로그램을 사용하여 Seccomp 필터를 작성하는 방법을 알아봅니다. 그런 다음 Linux 보안 모듈용 커널에 포함된 내장 BPF 후크를 살펴보겠습니다.

LSM(Linux 보안 모듈)은 표준화된 방식으로 다양한 보안 모델을 구현하는 데 사용할 수 있는 기능 세트를 제공하는 프레임워크입니다. LSM은 Apparmor, SELinux 및 Tomoyo와 같은 커널 소스 트리에서 직접 사용할 수 있습니다.

Linux의 기능에 대해 논의하는 것부터 시작하겠습니다.

기능

Linux 기능의 핵심은 특정 작업을 수행하기 위해 권한이 없는 프로세스 권한을 부여해야 하지만 해당 목적으로 suid를 사용하지 않고 프로세스에 권한을 부여하여 공격 가능성을 줄이고 프로세스가 특정 작업을 수행할 수 있도록 허용해야 한다는 것입니다. 예를 들어, 애플리케이션이 루트로 프로세스를 실행하는 대신 권한 있는 포트(예: 80)를 열어야 하는 경우 간단히 CAP_NET_BIND_SERVICE 기능을 제공할 수 있습니다.

main.go라는 Go 프로그램을 생각해 보세요.

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

이 프로그램은 포트 80(특권 포트)에서 HTTP 서버를 제공합니다. 일반적으로 컴파일 직후에 실행합니다.

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

그러나 루트 권한을 부여하지 않기 때문에 이 코드는 포트를 바인딩할 때 오류를 발생시킵니다.

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

capsh(쉘 관리자)는 특정 기능 세트를 사용하여 쉘을 실행하는 도구입니다.

이 경우 이미 언급한 것처럼 전체 루트 권한을 부여하는 대신 이미 프로그램에 있는 다른 모든 기능과 함께 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' - 사용자를 변경해야 하기 때문에(루트로 실행하고 싶지 않음) cap_net_bind_service와 실제로 사용자 ID를 변경할 수 있는 기능을 다음에서 지정합니다. 아무도, 즉 cap_setuid 및 cap_setgid에 루트가 없습니다.
• —keep=1 — 루트 계정에서 전환할 때 설치된 기능을 유지하려고 합니다.
• —user=“nobody” — 프로그램을 실행하는 최종 사용자는 누구도 아닙니다.
• —addamb=cap_net_bind_service — 루트 모드에서 전환한 후 관련 기능 지우기를 설정합니다.
• - -c "./capability" - 프로그램을 실행하기만 하면 됩니다.

연결된 기능은 현재 프로그램이 execve()를 사용하여 하위 프로그램을 실행할 때 하위 프로그램에 상속되는 특별한 종류의 기능입니다. 연결이 허용된 기능, 즉 환경 기능만 상속될 수 있습니다.

--caps 옵션에서 기능을 지정한 후 +eip가 무엇을 의미하는지 궁금할 것입니다. 이러한 플래그는 다음 기능을 결정하는 데 사용됩니다.

-활성화되어야 합니다(p).

- 사용 가능(e)

-자식 프로세스에 의해 상속될 수 있습니다(i).

cap_net_bind_service를 사용하고 싶기 때문에 e 플래그를 사용하여 이 작업을 수행해야 합니다. 그런 다음 명령에서 셸을 시작합니다. 그러면 기능 바이너리가 실행되며 이를 i 플래그로 표시해야 합니다. 마지막으로 p를 사용하여 기능을 활성화하려고 합니다(UID를 변경하지 않고 이 작업을 수행했습니다). cap_net_bind_service+eip처럼 보입니다.

ss를 사용하여 결과를 확인할 수 있습니다. 페이지에 맞게 출력을 조금 줄이면 0이 아닌 관련 포트와 사용자 ID(이 경우 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을 참조하세요.

프로그램을 작성할 때 개발자는 런타임 시 프로그램에 필요한 모든 기능을 미리 알지 못하는 경우가 많습니다. 또한 이러한 기능은 새 버전에서 변경될 수 있습니다.

프로그램의 기능을 더 잘 이해하기 위해 cap_capable 커널 기능에 대한 kprobe를 설정하는 BCC 지원 도구를 사용할 수 있습니다.

/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

cap_capable 커널 함수에서 단일 라이너 kprobe와 함께 bpftrace를 사용하여 동일한 결과를 얻을 수 있습니다.

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입니다. 이는 식별자 10을 갖는 include/uapi/linux/ability.h 파일의 커널 소스 코드에서 상수로 정의됩니다.

/* 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는 보안 컴퓨팅(Secure Computing)을 의미하며 개발자가 특정 시스템 호출을 필터링할 수 있도록 Linux 커널에 구현된 보안 계층입니다. Seccomp의 기능은 Linux와 비슷하지만 특정 시스템 호출을 관리하는 기능으로 인해 Linux에 비해 훨씬 더 유연해졌습니다.

Seccomp와 Linux 기능은 상호 배타적이지 않으며 두 접근 방식의 이점을 얻기 위해 함께 사용되는 경우가 많습니다. 예를 들어 프로세스에 CAP_NET_ADMIN 기능을 제공하지만 소켓 연결을 허용하지 않고 accept 및 accept4 시스템 호출을 차단할 수 있습니다.

Seccomp 필터링 방식은 SECCOMP_MODE_FILTER 모드로 동작하는 BPF 필터를 기반으로 하며, 시스템 콜 필터링은 패킷과 동일하게 수행된다.

Seccomp 필터는 PR_SET_SECCOMP 작업을 통해 prctl을 사용하여 로드됩니다. 이러한 필터는 seccomp_data 구조로 표시되는 각 Seccomp 패킷에 대해 실행되는 BPF 프로그램의 형태를 취합니다. 이 구조에는 참조 아키텍처, 시스템 호출 시 프로세서 명령에 대한 포인터, uint64로 표시되는 최대 XNUMX개의 시스템 호출 인수가 포함되어 있습니다.

linux/seccomp.h 파일의 커널 소스 코드에서 seccomp_data 구조는 다음과 같습니다.

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_O_TRACESECCOMP를 사용하여 ptrace 추적자에게 알리는 데 사용됩니다. 추적 프로그램이 연결되어 있지 않으면 오류가 반환되고 errno는 -ENOSYS로 설정되며 시스템 호출은 실행되지 않습니다.

- SECCOMP_RET_LOG - 시스템 호출이 해결되고 기록됩니다.

- SECCOMP_RET_ALLOW - 시스템 호출이 허용됩니다.

ptrace는 프로세스 실행을 모니터링하고 제어하는 ​​기능을 갖춘 추적 메커니즘을 Tracee라는 프로세스에 구현하기 위한 시스템 호출입니다. 추적 프로그램은 실행에 효과적으로 영향을 미치고 피추적자의 메모리 레지스터를 수정할 수 있습니다. Seccomp 컨텍스트에서는 SECCOMP_RET_TRACE 상태 코드에 의해 트리거될 때 ptrace가 사용되므로 추적 프로그램은 시스템 호출이 실행되는 것을 방지하고 자체 논리를 구현할 수 있습니다.

Seccomp 오류

때때로 Seccomp로 작업하는 동안 SECCOMP_RET_ERRNO 유형의 반환 값으로 식별되는 다양한 오류가 발생합니다. 오류를 보고하기 위해 seccomp 시스템 호출은 1 대신 -0을 반환합니다.

다음과 같은 오류가 발생할 수 있습니다.

- EACCESS - 호출자는 시스템 호출을 할 수 없습니다. 이는 일반적으로 CAP_SYS_ADMIN 권한이 없거나 prctl을 사용하여 no_new_privs가 설정되지 않았기 때문에 발생합니다(이에 대해서는 나중에 설명하겠습니다).

— EFAULT — 전달된 인수(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),
  };

지침은 linux/filter.h 파일에 정의된 BPF_STMT 및 BPF_JUMP 매크로를 사용하여 설정됩니다.
지침을 살펴보겠습니다.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch))) - 시스템은 BPF_W라는 단어의 형태로 BPF_LD에서 로드 및 누적되며, 패킷 데이터는 고정 오프셋 BPF_ABS에 위치합니다.

- BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) - 누산기 상수 BPF_K의 아키텍처 값이 arch와 같은지 BPF_JEQ를 사용하여 확인합니다. 그렇다면 오프셋 0에서 다음 명령어로 점프하고, 그렇지 않으면 오프셋 3에서 점프하여(이 경우) 아치가 일치하지 않기 때문에 오류를 발생시킵니다.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr))) - BPF_ABS의 고정 오프셋에 포함된 시스템 호출 번호인 BPF_W라는 단어 형태로 BPF_LD에서 로드 및 누적됩니다.

— 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로 프로그램을 종료하고 결과적으로 err 변수의 숫자와 함께 SECCOMP_RET_ERRNO 오류가 발생합니다.

- BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW) - BPF_RET로 프로그램을 종료하고 SECCOMP_RET_ALLOW를 사용하여 시스템 호출이 실행되도록 허용합니다.

SECCOMP는 CBPF입니다.
컴파일된 ELF 개체나 JIT 컴파일된 C 프로그램 대신 명령 목록이 사용되는 이유가 궁금할 수 있습니다.

여기에는 두 가지 이유가 있습니다.

• 첫째, Seccomp는 eBPF가 아닌 cBPF(클래식 BPF)를 사용합니다. 즉, 레지스터는 없지만 예제에서 볼 수 있듯이 마지막 계산 결과를 저장하는 누산기만 있습니다.

• 둘째, Seccomp는 BPF 명령어 배열에 대한 포인터를 직접 받아들이고 다른 어떤 것도 받아들이지 않습니다. 우리가 사용한 매크로는 프로그래머 친화적인 방식으로 이러한 명령을 지정하는 데 도움이 됩니다.

이 어셈블리를 이해하는 데 도움이 더 필요하면 동일한 작업을 수행하는 의사코드를 고려하세요.

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

소켓_필터 구조에서 필터 코드를 정의한 후 코드와 계산된 필터 길이를 포함하는 sock_fprog를 정의해야 합니다. 이 데이터 구조는 나중에 실행할 프로세스를 선언하기 위한 인수로 필요합니다.

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

install_filter 함수에서 해야 할 일은 단 하나뿐입니다. 프로그램 자체를 로드하는 것입니다! 이를 위해 보안 컴퓨팅 모드로 들어가기 위한 옵션으로 PR_SET_SECCOMP를 사용하여 prctl을 사용합니다. 그런 다음 sock_fprog 유형의 prog 변수에 포함된 SECCOMP_MODE_FILTER를 사용하여 필터를 로드하도록 모드에 지시합니다.

  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를 설정해야 하며 이를 통해 하위 프로세스가 상위 프로세스보다 더 많은 권한을 받는 상황을 방지해야 합니다. 이를 통해 루트 권한 없이 install_filter 함수에서 다음 prctl 호출을 수행할 수 있습니다.

이제 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 오류로 기록이 차단된 것으로 나타났습니다. 이는 프로그램이 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)

이제 Seccomp BPF의 작동 방식을 이해하고 이를 사용하여 무엇을 할 수 있는지에 대한 좋은 아이디어를 얻었습니다. 하지만 cBPF 대신 eBPF를 사용하여 동일한 결과를 얻고 최대 성능을 활용하고 싶지 않으십니까?

eBPF 프로그램을 생각할 때 대부분의 사람들은 단순히 프로그램을 작성하고 관리자 권한으로 로드한다고 생각합니다. 이 설명은 일반적으로 사실이지만 커널은 다양한 수준에서 eBPF 개체를 보호하기 위한 일련의 메커니즘을 구현합니다. 이러한 메커니즘을 BPF LSM 트랩이라고 합니다.

BPF LSM 트랩

시스템 이벤트에 대한 아키텍처 독립적 모니터링을 제공하기 위해 LSM은 트랩 개념을 구현합니다. 후크 호출은 기술적으로 시스템 호출과 유사하지만 시스템 독립적이며 인프라와 통합됩니다. LSM은 추상화 계층이 다양한 아키텍처에서 시스템 호출을 처리할 때 발생하는 문제를 방지하는 데 도움이 될 수 있는 새로운 개념을 제공합니다.

이 글을 쓰는 시점에서 커널에는 BPF 프로그램과 관련된 XNUMX개의 후크가 있으며 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의 CTO입니다. 그는 Docker 지원 분야에서 일했으며 Runc, Go, BCC 도구 및 기타 오픈 소스 프로젝트 개발에 기여했습니다. Docker 프로젝트 작업과 Docker 플러그인 생태계 개발로 유명합니다. David는 Flame 그래프에 매우 열정적이며 항상 성능 최적화를 모색하고 있습니다.

로렌조 폰타나 Sysdig의 오픈 소스 팀에서 일하며 주로 커널 모듈과 eBPF를 통해 컨테이너 런타임 보안과 이상 탐지를 제공하는 Cloud Native Computing Foundation 프로젝트인 Falco에 중점을 두고 있습니다. 그는 분산 시스템, 소프트웨어 정의 네트워킹, Linux 커널 및 성능 분석에 열정을 갖고 있습니다.

» 책에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 발행인의 웹사이트
» 차례
» 발췌

Khabrozhiteley의 경우 쿠폰을 사용하여 25% 할인을 받으세요 - Linux

종이책을 결제하시면 전자책이 이메일로 발송됩니다.

출처 : habr.com