gpt4 book ai didi

linux - 禁用 Linux vsyscall vdso vvar

转载 作者:塔克拉玛干 更新时间:2023-11-03 00:44:15 27 4
gpt4 key购买 nike

我正在通过 seccomp 模式为自定义字节码解释器实现 Linux 安全沙箱。为了尽可能减少攻击面,我想在一个完全干净的虚拟地址空间中运行它。我只需要代码和数据段以及可用的堆栈,但我不需要 vsyscall、vdso 或 vvar。

有什么方法可以禁止为给定进程分配此页面吗?

最佳答案

基本上,不,如果您希望映射本身不可用,则必须全局禁用 vsyscall/vDSO。如果你只是想让程序不能调用vsyscall/vDSO syscalls,那么seccomp就可以做到。不过有一些注意事项:

参见 https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

On x86-64, vsyscall emulation is enabled by default. (vsyscalls are legacy variants on vDSO calls.) Currently, emulated vsyscalls will honor seccomp, with a few oddities:

  • A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to the vsyscall entry for the given call and not the address after the 'syscall' instruction. Any code which wants to restart the call should be aware that (a) a ret instruction has been emulated and (b) trying to resume the syscall will again trigger the standard vsyscall emulation security checks, making resuming the syscall mostly pointless.

  • A return value of SECCOMP_RET_TRACE will signal the tracer as usual, but the syscall may not be changed to another system call using the orig_rax register. It may only be changed to -1 order to skip the currently emulated call. Any other change MAY terminate the process. The rip value seen by the tracer will be the syscall entry address; this is different from normal behavior. The tracer MUST NOT modify rip or rsp. (Do not rely on other changes terminating the process. They might work. For example, on some kernels, choosing a syscall that only exists in future kernels will be correctly emulated (by returning -ENOSYS).

To detect this quirky behavior, check for addr & ~0x0C00 == 0xFFFFFFFFFF600000. (For SECCOMP_RET_TRACE, use rip. For SECCOMP_RET_TRAP, use siginfo->si_call_addr.) Do not check any other condition: future kernels may improve vsyscall emulation and current kernels in vsyscall=native mode will behave differently, but the instructions at 0xF...F600{0,4,8,C}00 will not be system calls in these cases.

Note that modern systems are unlikely to use vsyscalls at all -- they are a legacy feature and they are considerably slower than standard syscalls. New code will use the vDSO, and vDSO-issued system calls are indistinguishable from normal system calls.

所以模拟的 vsyscalls 可以被 seccomp 限制,vDSO 同样被 seccomp 限制。如果禁用 gettimeofday(),受限程序将无法通过模拟的 vsyscall、vDSO 或常规系统调用调用该系统调用。如果您使用 seccomp 以这种方式限制它们,您就不必担心它们创建的攻击面。

如果您担心攻击者会利用 vDSO 映射本身(不需要调用系统调用),那么我认为没有办法可靠地在每个进程的基础上禁用它。你可以阻止它被链接进来,但是很难阻止一个受损的字节码解释器分配内存并将其放回原处。不过,您可以使用 vdso=0 内核参数启动,这将在全局范围内禁用它,因此链接它不会有任何作用。

关于linux - 禁用 Linux vsyscall vdso vvar,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39114292/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com