Per security review with kang, we would like to use seccomp() or seccomp2() to provide additional security for the moz.build 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 moz.build evaluation process *before* untrusted moz.build 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 moz.build 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.
Maybe I should read man pages before writing comments.
Summary: Investigate seccomp() or seccomp2() for moz.build evaluation sandbox → Investigate seccomp() for moz.build evaluation sandbox
You need to log in before you can comment on or make changes to this bug.