软件沙盒：基础知识 (2025)

// 这些策略很大程度上受到 Docker 默认配置文件的影响。 // 在顶部完成进一步的定制： // // - 无论如何都要避免需要 root 的系统调用。这里的策略主要是供非特权用户（而不是内部具有 root 权限的容器）使用的。 // 系统调用不会有害，但会导致更大的 BPF 程序 // 进而产生更多开销。 // - 避免很少使用的系统调用，这些系统调用可能被滥用以在桌面应用程序上进行更多指纹识别。此类别主要包含对分析有用的系统调用（例如 mincore、cachestat）。 // - 将它们分为受 systemD 的 seccomp 过滤器集和 // OpenBSD 的承诺承诺启发的类别。 POLICY Aio { ALLOW { io_cancel, io_destroy, io_getevents, io_pgetevents, io_setup, io_submit } } POLICY BasicIo { ALLOW { read, readv, tee, vmsplice, write, writev, // ioctl() 绝对与通用/流/基本 I/O 无关。 ioctl() // 实际上是一个伪装的系统调用，设备驱动程序可以将其用于任何用途。然而，预计任何执行文件 I/O 或 // 套接字 I/O 或 TTY IO 的程序最终都会使用 ioctl() // 进行某些操作， // 因此让我们继续将其包含在 // 基本 IO 集中，以强制其他 IO 类别也包含它。 ioctl } } POLICY Clock { ALLOW {clock_getres,clock_gettime, gettimeofday, time, times } } // 兼容性怪癖。这一系列策略是在不同的存储库中维护的良好候选者。 POLICY CompatX86 { ALLOW { // 对于旧的 ABI 模拟很重要 individual(persona) { persona == /*PER_LINUX=*/0 ||角色== /*PER_LINUX32=*/8 ||角色== /*UNAME26=*/0x0020000 ||角色== /*PER_LINUX32|UNAME26=*/0x20008 || persona == 0xffffffff }, // 对于 x86 系列的 ABI 很重要。我们把它放在这里而不是 // c-runtime，因为其他架构不需要它。理想情况下，Kafel // 允许我们在 c 运行时中编写 arch_prctl@amd64 并且该规则 // 仅在我们为 amd64 架构构建时才包含在内。 arch_prctl } } POLICY CompatDB32 { ALLOW { remap_file_pages } } POLICY CompatSystemd { ALLOW { // SystemD 使用它来获取挂载 ID name_to_handle_at } } POLICY CompatWine { ALLOW {modify_ldt } } POLICY Credentials { ALLOW { getegid, geteuid, getgid, getgroups, getresgid, getresuid, getuid } } POLICY CredentialsExtra { ALLOW { // SystemD 在策略“进程”中列出此系统调用，原因是 // 它能够查询任意进程，因此它是一个与进程关系相关的系统调用。遵循相同的推理，我们选择 //​​ 不将此系统调用包含在策略“凭据”中，因为该类别中的其他 // 系统调用不允许查询任意 // 进程。然而，我们也选择不将 capget 包含在“流程”类别中，因为该策略的大多数用法根本不需要 capget // 并且只会使生成的 BPF 更大。 capget } } POLICY CredentialsMutation { ALLOW { capset, setfsgid, setfsuid, setgid, setgroups, setregid, setresgid, setresuid, setreuid, setuid } } // 内存分配、线程、系统调用交互（或 libc 支持）和 // 应始终可用的函数（例如，exit_group 作为程序的最后手段）。 // // 请注意，实际打开一个基于 libc 的程序需要访问 // 更多的系统调用，因为加载程序将在文件系统中抓取 // 所需的库，并执行许多操作将程序映像拼接在一起。这里的想法是应用一个过滤器，允许 C 运行时在 RAM 中拥有程序映像后继续运行。 POLICY CRuntime { 允许 { brk、exit、exit_group、futex、futex_requeue、futex_wait、futex_waitv、futex_wake、get_robust_list、get_thread_area、gettid、madvise、map_shadow_stack、membarrier、mmap、mprotect、mremap、munmap、restart_syscall、rseq、sched_yield、 set_robust_list, set_thread_area, set_tid_address, // glibc 的 malloc() 引用了 getrandom()，因此它包含在此处 getrandom } } // 这些系统调用已经由 YAMA 的 ptrace_scope 或功能控制 // （例如 CAP_PERFMON）。通常的推理是允许它们是安全的，但是： // // - 它们实际上只对过程检查/调试有用。 // - 对于 IPC 使用，存在更好的机制（例如，可以使用 memfd+seal+mmap // 在协作进程之间实现零复制 I/O）。 // - 它们过去出现在一些 CVE 中。 POLICY Debug { ALLOW { kcmp, pidfd_getfd, perf_event_open, process_madvise, process_mrelease, process_vm_readv, process_vm_writev, ptrace } } POLICY FileDescriptors { ALLOW { close, close_range, dup, dup2, dup3, fcntl } } // 此策略与文件系统分离，因此进程仍然可以执行 //文件 IO on: // // - 已经打开的文件。 // - 从 UNIX 套接字接收的文件。 // - Memfds。 POLICY FileIo { ALLOW { copy_file_range, fadvise64,fallocate,flock, ftruncate, lseek, pread64, preadv, preadv2, pwrite64, pwritev, pwritev2, readahead, sendfil