Date: Tue, 28 Jul 2020 16:50:17 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248335] O_BENEATH leaks information about parent directories Message-ID: <bug-248335-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248335 Bug ID: 248335 Summary: O_BENEATH leaks information about parent directories Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: sunfish@mozilla.com The behaviour of `O_BENEATH` in code like this: ```c int dirfd =3D open("/foo", O_RDONLY); int bar =3D openat(dirfd, "/foo/bar", O_RDONLY|O_BENEATH); ``` on FreeBSD-CURRENT, if I read the man page [0] correctly, is to attempt to = open the absolute path "/foo/bar", since "/foo" is a prefix that "ends up at the topping directory". `openat` with `O_BENEATH` also resolves ".." paths which temporarily escape the topping directory if the final path is within the topping directory. These means that information about the path above the topping directory leaks through the result of the `openat`. This is undesir= able for sandboxing applications which wish to avoid leaking information about t= he host filesystem outside the sandbox. One way to avoid this is to enable Capsicum capability mode, however since = that affects process-wide state, it isn't suitable for lightweight sandboxing use cases which just want to sandbox paths in selected `openat` calls. And, it appears to have the side effect of disallowing ".." entirely. Another way to avoid this is for these use cases to check for absolute paths and ".." manually, however this wouldn't protect against symlinks to absolu= te paths or symlinks containing "..", which can't always be prevented. It may = also have the side effect of disallowing ".." entirely--there are techniques for emulating sandboxed ".." resolution [4], however they incur significant overhead. FreeBSD's `O_BENEATH` was modified to have its current behaviour in D17714 = [3]. It's unclear from the discussion what the motivating use cases are. For the= use case of sandboxing untrusted paths, it would be desirable to have a way to avoid leaking information about the host filesystem above the topping directory. FreeBSD's current `O_BENEATH` also appears to differ from Linux's new `openat2`'s `RESOLVE_BENEATH` flag, or any of its other flags [1]. Linux's `openat2` with `RESOLVE_BENEATH` fails with `EACCES` on any absolute path, = or any path that escapes even temporarily in an intermediate component. As an additional data point, this is the behaviour of CloudABI's `libemulator` as well [2]. I'm not very familiar with FreeBSD, so corrections if I've misunderstood or missed anything are most welcome! [0] https://svnweb.freebsd.org/base/head/lib/libc/sys/open.2?revision=3D340347&= view=3Dmarkup&pathrev=3D340347 [1] https://man7.org/linux/man-pages/man2/openat2.2.html [2] https://github.com/NuxiNL/cloudabi-utils/blob/master/src/libemulator/posix.= c#L1271 [3] https://reviews.freebsd.org/D17714 [4] https://github.com/NuxiNL/cloudabi-utils/blob/master/src/libemulator/posix.= c#L1205 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248335-227>