[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object

[vini.ipsmaker at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11767

Vinícius dos Santos Oliveira <vini.ipsmaker at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vini.ipsmaker at gmail dot com

--- Comment #51 from Vinícius dos Santos Oliveira <vini.ipsmaker at gmail dot com> ---
> Another very important case
> for such extensions that wasn't
> yet mentioned, is when you
> want to pre-open the existing
> solib on your program's init,
> and then restrict the FS access
> with landlock, so that you can't
> access that file on an FS
> afterwards.

I explored UNIX capability sandboxes on Linux and FreeBSD for the past few
years. For this purpose, Linux is several years behind FreeBSD (both on
kernel-side and userspace APIs). I discussed the challenges in sandboxing on
Linux and FreeBSD extensively in this article:
<https://blog.emilua.org/2025/01/12/software-sandboxing-basics/>.

fdlopen is mentioned in my article.

FreeBSD added fdlopen 14 years ago for a concrete use case: allow tests (e.g.
file permissions) to be done on the file before committing to load it in a
relatively race-free manner:
https://freebsd-arch.freebsd.narkive.com/phl97wbJ/fdlopen-3

That's not a ideological reason. That's a concrete use-case. That's not
supported on Linux/glibc.

Android's libc (bioniC) does have fdlopen (under a different name):
ANDROID_DLEXT_USE_LIBRARY_FD/library_fd on android_dlopen_ext:
https://developer.android.com/ndk/reference/structandroid/dlextinfo

An example sandboxing program where fdlopen would help me: load tdlib
(developed by Telegram) inside a sandbox so I don't have to implement the
Telegram protocol to talk to Telegram servers. I don't want Telegram developers
(the ones behind tdlib) to have arbitrary access to files on my system. Only
tdlib needs to be sandboxed as I'll develop the rest of the client/GUI myself.
The damn thing has over 16k commits (that's pretty much a constantly moving
target that's impossible to audit so sandboxing is a better answer):
https://github.com/tdlib/td

In general exec()'ing into a binary kills every use-case for plugins: sharing
data structures (not mere pipes behind shared file descriptors) among code
under the same security domain/jurisdiction. fdlopen is the *only* answer for
sandboxing libraries/plugins. FreeBSD had fdlopen 14 years ago yet on Linux
there's not even a plan to include such functionality.

Patches to add fdlopen on musl were sent 3 years ago yet nothing came out of
that: https://www.openwall.com/lists/musl/2023/05/08/4

Musl developers accuse fdlopen as something you only want for "ideological
reasons":
https://inbox.vuxu.org/musl/20240801025445.GQ10433@brightrain.aerifal.cx/

It seems to me that trying to talk to Linux userspace API developers is a
losing battle and not worth the effort at all.

On the other hand, every time I interacted with the FreeBSD community to
include APIs that would fix the gaps for my use cases... I had a collaboration
that was much more fruitful. I wish for the day when Linux userspace API
developers learn from FreeBSD folks. It just gets everyone stuck doing only
what was possible in the 80s and nothing more.

-- 
You are receiving this mail because:
You are on the CC list for the bug.