The semantics are the same as the other bases, except that in the
fsopen() case we will have to create a temporary instance for the
operation.
We want to set subset=pid,hidepid=ptraceable for the global procfs
handle (to restrict the scope if the handle was leaked into a
container). Unfortunately we also need to access stuff outside of
/proc/$pid such as sysctls (/proc/sys/*), and we plan to allow users to
access stuff in the root of /proc eventually.
So, in order to balance these two requirements, we can just create a
temporary procfs handle whenever we need to access stuff outside of the
root (which should be far more rare than accessing things inside
/proc/$pid) and use it as a fallback if the global procfs handle return
ENOENT. This will increase the overhead of accessing stuff outside
/proc/$pid, but the security benefits should be well worth it.
Fixes #69 (the temporary handle trick solves the main concerns with a global handle)
Fixes #62
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
The semantics are the same as the other bases, except that in the fsopen() case we will have to create a temporary instance for the operation.
We want to set subset=pid,hidepid=ptraceable for the global procfs handle (to restrict the scope if the handle was leaked into a container). Unfortunately we also need to access stuff outside of /proc/$pid such as sysctls (/proc/sys/*), and we plan to allow users to access stuff in the root of /proc eventually.
So, in order to balance these two requirements, we can just create a temporary procfs handle whenever we need to access stuff outside of the root (which should be far more rare than accessing things inside /proc/$pid) and use it as a fallback if the global procfs handle return ENOENT. This will increase the overhead of accessing stuff outside /proc/$pid, but the security benefits should be well worth it.
Fixes #69 (the temporary handle trick solves the main concerns with a global handle) Fixes #62 Signed-off-by: Aleksa Sarai cyphar@cyphar.com