|
|
Subscribe / Log in / New account

process_madvise(), pidfd capabilities, and the revenge of the PIDs

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 21:17 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: process_madvise(), pidfd capabilities, and the revenge of the PIDs by dskoll
Parent article: process_madvise(), pidfd capabilities, and the revenge of the PIDs

Well... you *could* have something like this:

long process_syscall(int pidfd, long number, ...)

It would behave as-if process had invoked syscall(2) with the remaining arguments. Maybe you also whitelist number to syscalls that actually make sense to invoke remotely, and are unlikely to cause massive reentrancy or threading issues.


to post comments

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 22, 2020 2:42 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

There are many states that thread could be in that would be problematic. Most of the time the thread would be blocked in the kernel for some reason, in which case you'd want to queue the syscall for execution when it would next return to userspace, but that might never happen.

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 23, 2020 19:03 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

It was mostly a tongue-in-cheek suggestion, and I'm pretty sure actually doing this would be a Bad Idea. But if you really wanted to do it, you could probably use the signals API to deal with those issues. That is:

  1. Create a new SIGFOO value, and make all of the sigaction() et al. functions accept it.
  2. Whenever someone calls process_syscall(), the target process receives a SIGFOO.
  3. The default behavior of the SIGFOO is to call syscall(...) as if from a signal handler.
  4. If the signal is masked, handled, or ignored, it behaves as you would expect (syscall() is not invoked).
  5. (Optional) Masking, handling, or ignoring the signal requires a capability and/or UID=0, so that containers cannot veto the actions of their supervisors. Alternatively, it can't be masked, handled, or ignored at all, so that it behaves like SIGSTOP and SIGKILL.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds