Investigate seccomp() for evaluation sandbox



Developer Services
3 years ago
a year ago


(Reporter: gps, Unassigned)





3 years ago
Per security review with kang, we would like to use seccomp() or seccomp2() to provide additional security for the evaluation process.

Looking at things under strace, I *think* this is doable. Unprivileged processes can put themselves under a seccomp policy, effectively locking themselves. If we do this from the evaluation process *before* untrusted code is evaluated, looking at strace, it appears the only system calls performed are open(), fstat(), lseek(), and close() (for reading files under .hg) and a write() for sending output to stdout.

Using seccomp2(), we could probably construct a policy limiting file I/O to certain paths (the repository being accessed). This would be easiest.

If we want to get fancy, we could implement a custom I/O layer in Mercurial that knows how to read from previously open file descriptors. We know which files we're seeking metadata on. We can ask Mercurial for the list of files in the revision. From there, we know which files are relevant. We can pre-open those files, define a mapping of path to file descriptor, seccomp() the process, and profit. This is a bit of work and it is a very low-level hack in Mercurial. If we can implement I/O whitelisting via seccomp2(), that seems preferred.

Comment 1

3 years ago
Maybe I should read man pages before writing comments.
Summary: Investigate seccomp() or seccomp2() for evaluation sandbox → Investigate seccomp() for evaluation sandbox
QA Contact: hwine → klibby
You need to log in before you can comment on or make changes to this bug.