containers
`PR_SET_PDEATHSIG` is racy unless there is a check for the parent having already died
If the parent process has died already, PR_SET_PDEATHSIG is a no-op. I consider this a kernel bug, but there is a workaround: if one knows what the parent process’s PID should be, one can compare the return value of getppid() to it. If they are different, raise the appropriate signal.
PR_SET_PDEATHSIG can be circumvented by a subsequent call unless it is blocked by seccomp, blocked by an LSM (like Yama), or bubblewrap is not dumpable and no other process in the same or child PID namespace has CAP_SYS_PTRACE. Bubblewrap should probably mark itself as non-dumpable to protect against the last scenario.
PR_SET_PDEATHSIGcan be circumvented by a subsequent call
I don't know what scenario you have in mind, but if you believe you have found a security vulnerability, please report it privately.
As far as I'm aware, bwrap's --die-with-parent is intended to be a convenience to get helper processes cleaned up automatically, rather than a security mechanism, so it's considered to be OK if there are ways it might not work. (But I'll defer to the authors of bubblewrap on this, if they have an opinion.)
PR_SET_PDEATHSIGcan be circumvented by a subsequent callI don't know what scenario you have in mind, but if you believe you have found a security vulnerability, please report it privately.
As far as I'm aware, bwrap's
--die-with-parentis intended to be a convenience to get helper processes cleaned up automatically, rather than a security mechanism, so it's considered to be OK if there are ways it might not work. (But I'll defer to the authors of bubblewrap on this, if they have an opinion.)
That this is racy is well-known, so I didn't see this as a security vulnerability.
As far as I'm aware, bwrap's
--die-with-parentis intended to be a convenience to get helper processes cleaned up automatically, rather than a security mechanism
Would it be of possible to document limitations/non-goals like this more clearly. Eg. in a CAVEATS section in the man page?
I tried to get this fixed in the kernel but the maintainers didn't seem to be interested. They recommend using cgroups to ensure that process trees are cleaned up.