Re:Io_uring and seccomp (2022)
by eqvinox on Saturday October 12, 2024 @06:43AM
(#41818144)
> I've witnessed many situations where seccomp sandbox broke because glibc/python interpreter started using a different syscall (for example openat with AT_FDCWD instead of open)
ACK, that's what I meant with "hard in a lot of cases"… to be honest I think this is a failure of the ecosystem at-large. It's a bit of a half feature without some kind of higher-level userspace mechanism to collect who needs what, especially when a bunch libraries are involved. It's admittedly a very hard problem, e.g. just because something is linking libcurl as a 2nd or 3rd level dependency doesn't mean you intend your process to ever make network connections… I don't think it's unsolveable though.
ACK, that's what I meant with "hard in a lot of cases"… to be honest I think this is a failure of the ecosystem at-large. It's a bit of a half feature without some kind of higher-level userspace mechanism to collect who needs what, especially when a bunch libraries are involved. It's admittedly a very hard problem, e.g. just because something is linking libcurl as a 2nd or 3rd level dependency doesn't mean you intend your process to ever make network connections… I don't think it's unsolveable though.