search

openSUSE / libpathrs

C-friendly API to make path resolution safer on Linux.
GNU Lesser General Public License v3.0
80 stars 6 forks source link

procfs: should we have a global handle at all? #69

Closed cyphar closed 1 month ago

cyphar commented 2 months ago

Due to the risk of leaks, programs joining a container need to be careful to use PR_SET_DUMPABLE and take other necessary precautions to avoid containers being able to access the internal proc handle. If we used a regular open for /proc this could allow for a container breakout (and for proper mount fds an attacker could access files that are masked in the actual container).

On the other hand, we need to create these handles internally within libpathrs anyway (and creating it for each operation seems quite suboptimal) so maybe exposing the fact it exists is more useful to help tell users they need to be careful.

Ultimately, a program that is interacting with untrusted namespaces already needs to be careful and using libpathrs doesn't really change that. In the worst case, programs can use close_range to forcefully close the descriptor (I don't really want to make GLOBAL_PROCFS_HANDLE an RwMutex).

Maybe if we had a nice configure API it would be possible for paranoid users to specify the handle they want to use (which would make exposing ProcfsHandle::new in the C API make some sense).

cyphar commented 2 months ago

One option would be to keep the subset=pid around (because it should be somewhat safe to leak even if we did leak it, minus the possible pidns issues) and only create a temporary mount for stuff that needs to access stuff not in subset=pid. Then again fs.protected_symlinks needs to be checked many times. Maybe we can just check it once...?

EDIT: I forgot that we already cache fs.protected_symlinks. #72 implements this trick.