How does chromium renderer access filesystem on linux？

[lixin jiang]

Hello,

I'm trying to read the source code of seccomp-bpf sandbox of chromium. When I looked at its bpf policy of renderer, I found that when bpf meets with syscalls releated to filesystem access, it will just return a errno to user space instead of triggering a trap to forward those syscalls to broker process: 

[ ... ]

if (SyscallSets::IsFileSystem(sysno) ||

SyscallSets::IsCurrentDirectory(sysno)) {

return Error(fs_denied_errno);

}

[ ... ]

Source code of policy is here.

So I'm wondering how renderer accesses the filesystem?

[Matt Denton]

The renderer does not access the filesystem directly (via syscalls). If the renderer needs a file descriptor, the renderer is either forked with the file descriptor already installed, or the descriptor is sent to the renderer over Mojo at runtime. Seccomp-bpf is incapable of filtering by filepath and so it has to be this way.

--
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Matt Denton]

On Thu, Jan 5, 2023 at 7:04 PM lixin jiang <ylzsg...@gmail.com> wrote:

Thank you for your reply.

Do you mean that all the open syscalls in renderer will be replaced with the mojo operation?

 

Yes, but not automatically. The code needs to explicitly call a Mojo method.

Does the descriptor sent by mojo is opened by the broker process? If it is, there will not be a corresponding file descriptor table entry in the renderer process. So how does the renderer use this fd to operate that file?  

If you are referring to the browser process as the broker, then yes. The file descriptor will be transferred to the renderer using a Unix socket (see SCM_RIGHTS), so there will be a corresponding entry in the file descriptor table of the renderer process (note it will likely have a different file descriptor number).

Separately, utility processes also cannot access the filesystem, but since those are also used for third-party code, we have a "broker process" per utility process, and our seccomp-bpf code transparently rewrites open(...) syscalls into IPCs over to the broker process. However, this is separate from the renderer; renderer processes are not utility processes and vice-versa.

 

Matt Denton <mpde...@google.com> 于2023年1月6日周五 10:17写道：

[Matt Denton]

On Thu, Jan 5, 2023 at 7:42 PM lixin jiang <ylzsg...@gmail.com> wrote:

Excuse me.

I also want to ask what differences between the renderer process and the utility process makes developers choose to use two different strategies to achieve the access to system resources? 

Utility processes often contain third party code. Some third-party code cannot be reasonably edited to use Mojo, even via hooks. Especially shared objects (e.g. libpulse for audio or many of the gpu libraries) cannot be edited as they are prebuilt. So we need to support the automatic rewriting of open() syscalls when sandboxing third party code.

We don't use this for first-party code, as other platforms (e.g. Windows) do not support automatic rewriting of open() syscalls and so they need to use Mojo anyway. So renderers don't use the automatic rewriting/broker process.

 

lixin jiang <ylzsg...@gmail.com> 于2023年1月6日周五 11:16写道：

I get it. 

Thank you very much.

Matt Denton <mpde...@google.com> 于2023年1月6日周五 11:12写道：