[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

[Demi Marie Obenour]

> > That is definitely a step forward, especially if the hashing is performed in the parent process. I imagine `SECCOMP_SET_MODE_STRICT` would be pretty hard to break out of, and would dramatically reduce my worries about this patch. Is setting up `SECCOMP_SET_MODE_STRICT` before decompression a viable option?
> 
> @DemiMarie so I looked a bit more into `seccomp`. Unfortunately strict mode is.... too strict with only read/write/_exit, nd sigreturn. With a bit of fiddling with `SECCOMP_RET_TRAP`, this is the list I came up with in order to get the decompression to work: https://gist.github.com/chantra/0fd33c338ba7465d87222b68bab76e70

That still looks fairly tight.  You need to make sure that all unnecessary file descriptors have been closed, since otherwise a compromised process could use them without interference from seccomp.  I suggest pointing FDs 0, 1, and 2 at `/dev/null`, and closing all of the others except for the ones that the decompressor is using.  seccomp also supports parameter filtering, and I suggest using it for `futex` and other syscalls.  Also, as a defense-in-depth measure, it is best to drop privileges by chrooting into `/var/empty` or a deleted directory, and by switching to an unprivileged user.  I recommend `SECCOMP_RET_KILL_PROCESS` instead of `SECCOMP_RET_KILL`, since it kills all threads.

For sandboxing to be useful, the output of the sandboxee must be assumed untrusted.  Hash computations must be done in the parent, for example.  Also note that programs that call RPM may be multi-threaded, and using any non-async-signal-safe operation in the child process after `fork()` is undefined behavior for a multi-threaded parent.  Ideally, that means you should `execve()` a new process that would then sandbox itself.  In practice, I believe that glibc makes at least `malloc()` work.  Using seccomp in a dedicated thread will appear to work, but it won’t actually provide any benefit since the address space is still shared.

> As much as portability, AFAIK, not all architectures are covered, but I may be wrong. There is likely some corner cases here. For one, the FD_t layer adds stats computation to the read/write operations and within that lays calls to [`gettimeofday`](https://github.com/rpm-software-management/rpm/blob/07f1d3132f0c7b7ecb69a47a9930edb534a9250e/rpmio/rpmsw.c#L21), which may or may not be a vsdo, so probably another one to add to the list.

That is a good idea.  I recommend disabling RPM-CoW by default on architectures where a sandbox is not available.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-1036468986
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1470/c1036468986 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220211/f4c09e16/attachment-0001.html>