書籍「Linux モニタリング用 BPF」

ハブロ住民の皆さん、こんにちは！ BPF 仮想マシンは、Linux カーネルの最も重要なコンポーネントの XNUMX つです。 これを適切に使用すると、システム エンジニアは障害を発見し、最も複雑な問題でも解決できるようになります。 カーネルの動作を監視および変更するプログラムの作成方法、カーネル内のイベントを監視するコードを安全に実装する方法などを学びます。 David Calavera と Lorenzo Fontana が、BPF の力を解き放つお手伝いをします。 パフォーマンスの最適化、ネットワーキング、セキュリティに関する知識を深めます。 - BPF を使用して、Linux カーネルの動作を監視および変更します。 - カーネルを再コンパイルしたりシステムを再起動したりすることなく、コードを挿入してカーネル イベントを安全に監視します。 — C、Go、または Python の便利なコード例を使用します。 - BPF プログラムのライフサイクルを所有して制御します。

Linux カーネルのセキュリティ、その機能、および Seccomp

BPF は、安定性、セキュリティ、速度を犠牲にすることなくカーネルを拡張する強力な方法を提供します。 このため、カーネル開発者は、BPF プログラムでサポートされる Seccomp フィルター (Seccomp BPF とも呼ばれます) を実装することで、その多用途性を利用して Seccomp のプロセス分離を改善するのが得策であると考えました。 この章では、Seccomp とは何か、またその使用方法について説明します。 次に、BPF プログラムを使用して Seccomp フィルターを作成する方法を学びます。 その後、Linux セキュリティ モジュールのカーネルに含まれる組み込み BPF フックを見ていきます。

Linux セキュリティ モジュール (LSM) は、標準化された方法でさまざまなセキュリティ モデルを実装するために使用できる一連の機能を提供するフレームワークです。 LSM は、Apparmor、SELinux、Tomoyo などのカーネル ソース ツリーで直接使用できます。

まずは Linux の機能について説明しましょう。

機能

Linux の機能の本質は、特定のタスクを実行するために非特権プロセスのアクセス許可を付与する必要があることですが、その目的で suid を使用したり、その他の方法でプロセスに特権を与えたりすることで、攻撃の可能性を減らし、プロセスが特定のタスクを実行できるようにする必要があります。 たとえば、アプリケーションが特権ポート (たとえば 80) を開く必要がある場合、プロセスを root として実行する代わりに、単純に 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

ただし、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 を誰にも与えません。つまり、cap_setuid と cap_setgid です。
• —keep=1 — root アカウントから切り替えるときに、インストールされている機能を保持したいとします。
• —user=“nobody” — プログラムを実行するエンド ユーザーは誰でもありません。
• —addamb=cap_net_bind_service — root モードから切り替えた後の関連機能のクリアを設定します。
• - -c "./capabilities" - プログラムを実行するだけです。

リンクされた機能は、現在のプログラムが 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 カーネル関数で bpftrace とワンライナー kprobe を使用することで、同じことを実現できます。

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 番目の列はプロセスに必要な機能であり、この出力には非監査イベントが含まれているため、すべての非監査チェックが表示され、最後に監査フラグ (出力の最後) が 10 に設定された必要な機能が表示されます。私たちが興味があるのは CAP_NET_BIND_SERVICE で、これはファイル include/uapi/linux/ability.h のカーネル ソース コードで識別子 XNUMX の定数として定義されています。

/* 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 トレーサに通知するために使用されます。 - PTRACE_O_TRACESECCOMP を使用して、そのプロセスを確認および制御するためにシステム コールが実行されたときにインターセプトします。 トレーサが接続されていない場合はエラーが返され、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 — ここには XNUMX つの理由が考えられます。

- 要求された操作は不明であるか、現在の構成のカーネルによってサポートされていません。

-指定されたフラグは、要求された操作に対して無効です。

-operation には BPF_ABS が含まれていますが、指定されたオフセットに問題があり、seccomp_data 構造体のサイズを超える可能性があります。

- フィルターに渡される命令の数が最大値を超えています。

— ENOMEM — プログラムを実行するのに十分なメモリがありません。

- EOPNOTSUPP - 操作は、SECCOMP_GET_ACTION_AVAIL でアクションが利用可能であることを示しましたが、カーネルは引数での戻りをサポートしていません。

— ESRCH — 別のストリームを同期するときに問題が発生しました。

- ENOSYS - SECCOMP_RET_TRACE アクションに関連付けられたトレーサーはありません。

prctl は、ユーザー空間プログラムがバイト エンディアン、スレッド名、安全な計算モード (Seccomp)、特権、Perf イベントなどのプロセスの特定の側面を操作 (設定および取得) できるようにするシステム コールです。

Seccomp はサンドボックス テクノロジのように見えるかもしれませんが、そうではありません。 Seccomp は、ユーザーがサンドボックス メカニズムを開発できるようにするユーティリティです。 次に、Seccomp システム コールによって直接呼び出されるフィルターを使用して、ユーザー インタラクション プログラムがどのように作成されるかを見てみましょう。

BPF Seccomp フィルターの例

ここでは、前に説明した次の XNUMX つのアクションを組み合わせる方法を示します。

— 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

コードの残りの部分は、XNUMX つの部分からなる 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_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_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 | (error & 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 プログラムの代わりに命令のリストが使用されるのか疑問に思われるかもしれません。

これにはXNUMXつの理由があります。

• 第一に、Seccomp は eBPF ではなく cBPF (クラシック BPF) を使用します。つまり、例に見られるように、レジスタはなく、最後の計算結果を保存するアキュムレータのみがあります。

• 第 XNUMX に、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 関数でやるべきことは XNUMX つだけ残っています。それはプログラム自体をロードすることです。 これを行うには、prctl を使用し、セキュア コンピューティング モードに入るオプションとして PR_SET_SECCOMP を選択します。 次に、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 を設定する必要があります。これにより、子プロセスが親プロセスよりも多くの権限を受け取る状況を回避できます。 これにより、root 権限がなくても、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 オブジェクトに保護を提供し、適切な権限を持つユーザーだけがカードやプログラムで操作を実行できるようにするというものです。

サマリー

セキュリティは、保護したいものすべてに対して画一的な方法で実装できるものではありません。 さまざまなレベルおよびさまざまな方法でシステムを保護できることが重要です。 信じられないかもしれませんが、システムを保護する最善の方法は、さまざまな立場からさまざまなレベルの保護を組織し、XNUMX つのレベルのセキュリティを低下させてもシステム全体へのアクセスが許可されないようにすることです。 コア開発者は、さまざまなレイヤーとタッチポイントのセットを提供するという素晴らしい仕事をしてくれました。 レイヤーとは何か、またそれらを操作するために BPF プログラムを使用する方法について十分に理解できたことを願っています。

著者について

デビッド・カラベラ Netlify の CTO です。 彼は Docker サポートに携わり、Runc、Go、BCC ツールやその他のオープンソース プロジェクトの開発に貢献しました。 Docker プロジェクトと Docker プラグイン エコシステムの開発に関する仕事で知られています。 David はフレーム グラフに非常に情熱を持っており、常にパフォーマンスの最適化に努めています。

ロレンツォフォンタナ Sysdig のオープンソース チームに所属しており、カーネル モジュールと eBPF を介してコンテナ ランタイム セキュリティと異常検出を提供する Cloud Native Computing Foundation プロジェクトである Falco に主に焦点を当てています。 彼は、分散システム、ソフトウェア定義ネットワーキング、Linux カーネル、およびパフォーマンス分析に情熱を注いでいます。

» この本の詳細については、こちらをご覧ください。 出版社のウェブサイト
» 目次
» 抜粋

Khabrozhiteley の場合、クーポン使用で 25% 割引 - Linux

紙版の書籍をお支払いいただくと、電子書籍が電子メールで送信されます。

出所： habr.com