File paths?

Posted Jun 4, 2018 21:37 UTC (Mon) by wahern (subscriber, #37304)
In reply to: File paths? by Cyberax
Parent article: Deferring seccomp decisions to user space

Isn't that susceptible to a race condition? systrace (https://en.wikipedia.org/wiki/Systrace) never saw widespread adoption exactly because of the race condition, both on Linux and on OpenBSD (with an in-kernel implementation). The TOCTTOU race is that a signal handler or thread changes the path between the check and the actual open.

The solution is to copy the path or otherwise make it immutable. That's costly and it's why the the seccomp BPF filter originally didn't support processing the file path string. Has that changed?

File paths?

Posted Jun 4, 2018 21:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

No, there's no race condition. The kernel code would have to copy strings into the message sent to the userspace helper.

The helper code then can do all the required open/access/stat stuff and return the results as a file descriptor (open) or a static block of data (stat/access).

Obviously, copying the parameters will add some overhead, but it should be way less than doing additional ptrace/read_mem calls from the userspace helper.

File paths?

Posted Jun 5, 2018 19:26 UTC (Tue) by wahern (subscriber, #37304) [Link] (1 responses)

Is that how it works _now_? Is any of that work already in place?

File paths?

Posted Jun 5, 2018 21:34 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Right now BPF syscall filter programs can't access the string arguments at all, so there's no problem.