Hello kind people,
I am the main author of the Syd sandbox. I am here to describe an unexpected behaviour i noticed with Landlock's signal scoping. This may or may not be a bug within Landlock's context. It is a bug within Syd's context which we fixed. Decide for yourself and act accordingly :-)
Syd has signal protections. The goal, however, is more conservative than pid namespacing or landlock signal scoping. By design Syd shares namespaces, rootfs and sometimes even process group with the sandbox process and we do not want the sandbox process to interfere with Syd, even detecting its process id might be problematic. Therefore Syd has simple seccomp-notify filters to hook into kill, tkill, tgkill, rt_sigqueueinfo, rt_tgsigqueueinfo and pidfd_open to prevent this. Syd can't emulate these syscalls reliably but there're no pointer reads during syscall check either so this works.
It works but it has noticable overhead and limited in scope considered to Landlock signal scoping. Therefore we have recently added a check for landlock signal scoping at startup and if it's usable we just put a scope-only landlock domain between syd and the sandbox process and this is a much better solution. With SYD_ASSUME_KERNEL=<6.12 syd will revert to previous behaviour.
While auditing this part of Syd for differences between the seccomp protection and landlock protection, I have noticed Landlock's signal scoping allows the initial pidfd_open to grab a handle to the process. This on its own does not bring much, and Landlock will intervene at the next pidfd_send_signal and do its duty. At the moment apart from sending signals, one may call the process_mrelease syscall on the pidfd and that's not dangerous at all as it will return EINVAL for processes which are alive. However this may change gradually with the new additions to the pidfd API, be it new syscalls, or ioctls or alike.
It's not a problem now, it may or may not become a problem in the future. Starting with next version, Syd is going to hook into pidfd_open regardless of landlock signal scoping. Better safe than sorry and ESRCH is somewhat preferred over EACCES in this specific case.
Hello kind people,
I am the main author of the Syd sandbox. I am here to describe an unexpected behaviour i noticed with Landlock's signal scoping. This may or may not be a bug within Landlock's context. It is a bug within Syd's context which we fixed. Decide for yourself and act accordingly :-)
Syd has signal protections. The goal, however, is more conservative than pid namespacing or landlock signal scoping. By design Syd shares namespaces, rootfs and sometimes even process group with the sandbox process and we do not want the sandbox process to interfere with Syd, even detecting its process id might be problematic. Therefore Syd has simple seccomp-notify filters to hook into kill, tkill, tgkill, rt_sigqueueinfo, rt_tgsigqueueinfo and pidfd_open to prevent this. Syd can't emulate these syscalls reliably but there're no pointer reads during syscall check either so this works.
It works but it has noticable overhead and limited in scope considered to Landlock signal scoping. Therefore we have recently added a check for landlock signal scoping at startup and if it's usable we just put a scope-only landlock domain between syd and the sandbox process and this is a much better solution. With SYD_ASSUME_KERNEL=<6.12 syd will revert to previous behaviour.
While auditing this part of Syd for differences between the seccomp protection and landlock protection, I have noticed Landlock's signal scoping allows the initial pidfd_open to grab a handle to the process. This on its own does not bring much, and Landlock will intervene at the next pidfd_send_signal and do its duty. At the moment apart from sending signals, one may call the process_mrelease syscall on the pidfd and that's not dangerous at all as it will return EINVAL for processes which are alive. However this may change gradually with the new additions to the pidfd API, be it new syscalls, or ioctls or alike.
It's not a problem now, it may or may not become a problem in the future. Starting with next version, Syd is going to hook into pidfd_open regardless of landlock signal scoping. Better safe than sorry and ESRCH is somewhat preferred over EACCES in this specific case.