| 31 Mar 2025 |
niko ⚡️ | Nix has an explicit allow-list of syscalls | 20:35:49 |
niko ⚡️ | nothing from io_uring family is on that list | 20:35:59 |
niko ⚡️ | By design | 20:36:02 |
@r522:matrix.org | i'm looking at https://github.com/NixOS/nix/blob/5a8dedc45cc04a207917316c245e4993234bfbe0/src/libstore/unix/build/local-derivation-goal.cc and i don't see an allow list?
... i also don't see where io_uring is blocked though | 20:38:17 |
@r522:matrix.org | * i'm looking at https://github.com/NixOS/nix/blob/5a8dedc45cc04a207917316c245e4993234bfbe0/src/libstore/unix/build/local-derivation-goal.cc#L1774 and i don't see an allow list?
... i also don't see where io_uring is blocked though | 20:39:05 |
@r522:matrix.org | so i guess that's not what sets up the build sandbox | 20:39:17 |
niko ⚡️ | No, you're right, I'm too Lix-brained, Lix has an explicit syscall list, CppNix uses (for the most part) the default seccomp profile | 20:45:13 |
@r522:matrix.org | mhm
i will go look in lix to see where they do it then | 20:46:48 |
@r522:matrix.org | right, yeah, they do | 20:47:22 |
@r522:matrix.org | that being said, they don't seem to care about the exact path used for opens | 20:48:08 |
@r522:matrix.org | so it's seccomp but not in a way that inspects paths
actually, you can't do that anyways | 20:48:35 |
@r522:matrix.org | * so it's seccomp but not in a way that inspects paths
actually, you can't do that anyways with seccomp | 20:48:38 |
@r522:matrix.org | so allowing io_uring operations that are equal to syscalls that are already allowed would be fine | 20:48:57 |
@r522:matrix.org | unsure if you can set global io_uring restrictions though | 20:50:59 |
@r522:matrix.org | mhm yeah it's per-ring | 20:51:42 |
| 1 Apr 2025 |
@aloisw:julia0815.de | In reply to @r522:matrix.org so allowing io_uring operations that are equal to syscalls that are already allowed would be fine The problem is that seccomp cannot do that. | 04:38:41 |
| leona joined the room. | 08:42:50 |
@r522:matrix.org | yeah
it wouldn't be hard to make it do that, kernel-wise (or maybe LD_PRELOAD some shim that goes and asks for an already created ring that has syscall restrictions applied already)
but i guess ultimately it doesn't Particularly matter since all you lose is the ability to run tests in the sandbox | 10:42:38 |
K900 | In reply to @r522:matrix.org
yeah it wouldn't be hard to make it do that, kernel-wise (or maybe LD_PRELOAD some shim that goes and asks for an already created ring that has syscall restrictions applied already)
but i guess ultimately it doesn't Particularly matter since all you lose is the ability to run tests in the sandbox There are no restrictions in io_uring | 10:47:58 |
K900 | That's kind of the problem | 10:48:04 |
@r522:matrix.org | there are, but it's per-ring | 10:48:33 |
@r522:matrix.org | not globally | 10:48:38 |
@r522:matrix.org | if there was a syscall to say "apply these restrictions to all future rings made by this process", it would be fine | 10:49:25 |
@r522:matrix.org | (see: IORING_REGISTER_RESTRICTIONS in https://www.man7.org/linux/man-pages/man2/io_uring_register.2.html) | 10:50:32 |
@aloisw:julia0815.de | That sounds very hard to implement correctly for a separate sandbox. | 11:09:57 |
@r522:matrix.org | well, the point behind restrictions is to let you make a ring and then hand it off to someone less privileged than you (since it's just a fd, sending fds is easy)
for that use case, making it per-ring is correct
but for the seccomp use case of "protecting you from yourself", yeah, it has to be global
| 11:26:04 |
| Adam Neverwas set a profile picture. | 23:15:46 |
| 3 Apr 2025 |
Toma | After I do some basic testing on darwin I think https://github.com/NixOS/nixpkgs/pull/390171 is good to go | 08:26:19 |
| @2xsaiko:tchncs.de changed their display name from 2xsaiko to 2xsaiko (moved! @saiko:knifepoint.net). | 12:52:01 |
| 4 Apr 2025 |
emily | https://github.com/nix-darwin/nix-darwin/issues/1418 is this a recent breaking change in the Rust builder interface? | 11:32:39 |