Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandboxing inside Docker #8

Open
Gorgeous-Patrick opened this issue Dec 5, 2024 · 11 comments
Open

Sandboxing inside Docker #8

Gorgeous-Patrick opened this issue Dec 5, 2024 · 11 comments

Comments

@Gorgeous-Patrick
Copy link

Gorgeous-Patrick commented Dec 5, 2024

我需要在docker 容器内运行sandbox,请问怎么实现。我现在尝试的方法是在docker privilege 模式下运行。
image
这个被运行程序是一个最简单的hello world。

#include<iostream>

int main() {
    std::cout << "Hello, world" << std::endl;
    return 0;
}

我了解到在docker里面使用sandbox技术可能有些困难,但是似乎您在go-judge项目当中完全将go-sandbox包装进了docker里面,我想请教一下这是如何完成的,谢谢!

@Gorgeous-Patrick
Copy link
Author

尝试了一下其他的runner
image

@criyle
Copy link
Owner

criyle commented Dec 5, 2024

使用到了容器嵌套技术,这个需要特权容器,需要 --privileged 参数启动容器

@Gorgeous-Patrick
Copy link
Author

感谢!我还遇到了另外一个问题。我在您的代码的基础上新增了一些allowed syscall来使我的hello world程序可以运行。但是我遇到了很奇怪的问题。按照我的理解,-show-trace-details参数是用来开启debug输出的,但是好像这个flag会影响结果:
image
图片中,上面一次运行是使用了-show-trace-details参数的结果,下面一次运行时没有使用的结果。可以看到不知为何,status code有变化。具体的代码上的改变,您可以看看PR #9 。感谢您的回复!

@criyle
Copy link
Owner

criyle commented Dec 5, 2024

使用 show-trace-details 会把默认阻止的 syscall 转为 trace ,有可能某些 syscall 并没有加入到同意名单当中。

@Gorgeous-Patrick
Copy link
Author

I see. 是不是意味着按照上图,我应该允许openat syscall呢?

@Gorgeous-Patrick
Copy link
Author

在把openat和access都设置为allow之后情况变成了这样,依然不一致:
image

@criyle
Copy link
Owner

criyle commented Dec 5, 2024

应该不是 openat 的问题,因为 openat 是默认 trace 的(需要检查打开的文件路径是否被允许)。可以尝试往前翻 log 找到具体的问题。

@Gorgeous-Patrick
Copy link
Author

Gorgeous-Patrick commented Dec 5, 2024

这个是disallow openat的情况下的之前的输出:
image

@criyle
Copy link
Owner

criyle commented Dec 6, 2024

目前可以定位到在子进程运行 execve 启动程序时丢出的 SIGSYS,可能是 SECCOMP BPF filter 出现了某种纰漏(比如错误的 syscall number)。从 git 历史追溯,两年前的版本也有问题(更早以前的版本和当前 go 版本不兼容)。
如果需要实现沙箱,当前更推荐使用容器版本的 runner 而不是 syscall trace 以获取更好的兼容性和性能。可以看看 https://github.com/criyle/go-judge

@criyle
Copy link
Owner

criyle commented Dec 6, 2024

这个行为应该是第三方 seccomp bpf 库的问题,正在询问上游解决方案 elastic/go-seccomp-bpf#40

@Gorgeous-Patrick
Copy link
Author

好的,谢谢。持续跟进中

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants