libdl, no fdlopen function

libdl, no fdlopen function

[connor horman]

Hello libc-help list,
libdl and <dlfcn.h> provides access to the runtime linker to allow programs
to load new shared objects at runtime. However, it only provides the
capability to load shared objects by name.
The freebsd libc provides an fdlopen function (See:
https://www.freebsd.org/cgi/man.cgi?query=fdlopen&sektion=3), which allows
you to open a shared object from a file descriptor. This has numerous
benefits, including the fact that you can test properties on the file
descriptor before loading it as a shared object (for example, you can
validate some signature on the shared object, or, in a privileged process,
check the file permissions to see if its owned by root + suid). Using
simply dlopen, a program cannot securely do this, as attempts to do so
would be vulnerable to TOCTOU exploits. (On linux systems with the /proc
filesystem, it is possible to write code that solves this, however it is
entirely a hack.)
I was wondering if there was a reason why glibc does not provide similar
functionality (even behind #define _BSD_SOURCE). It would likely be less
hacky than using the proc filesystem (and less prone to open("/proc",F_OK)
-> EACCESS/ENOENT).

Re: libdl, no fdlopen function

[Carlos O'Donell]

On 7/22/20 9:36 PM, connor horman via Libc-help wrote:
> Hello libc-help list,
> libdl and <dlfcn.h> provides access to the runtime linker to allow programs
> to load new shared objects at runtime. However, it only provides the
> capability to load shared objects by name.
> The freebsd libc provides an fdlopen function (See:
> https://www.freebsd.org/cgi/man.cgi?query=fdlopen&sektion=3), which allows
> you to open a shared object from a file descriptor. This has numerous
> benefits, including the fact that you can test properties on the file
> descriptor before loading it as a shared object (for example, you can
> validate some signature on the shared object, or, in a privileged process,
> check the file permissions to see if its owned by root + suid). Using
> simply dlopen, a program cannot securely do this, as attempts to do so
> would be vulnerable to TOCTOU exploits. (On linux systems with the /proc
> filesystem, it is possible to write code that solves this, however it is
> entirely a hack.)
> I was wondering if there was a reason why glibc does not provide similar
> functionality (even behind #define _BSD_SOURCE). It would likely be less
> hacky than using the proc filesystem (and less prone to open("/proc",F_OK)
> -> EACCESS/ENOENT).
 
There is no strong reason why we don't have fdlopen(). I'd like to see it
implemented. If someone wants to work on it that would be great.

I would also like to see something like dlopen_from() implemented per this
discussion: https://sourceware.org/pipermail/libc-help/2020-January/005107.html

-- 
Cheers,
Carlos.

Re: libdl, no fdlopen function

[connor horman]

I can look into implementing it. Having it available would be quite useful
as I want to do runtime dso signature verification. I'd have to look at the
code that deals with the actual runtime loading and see where the name gets
turned into a file descriptor.

On Wed, Jul 22, 2020 at 22:32 Carlos O'Donell <carlos@redhat.com> wrote:

> On 7/22/20 9:36 PM, connor horman via Libc-help wrote:
> > Hello libc-help list,
> > libdl and <dlfcn.h> provides access to the runtime linker to allow
> programs
> > to load new shared objects at runtime. However, it only provides the
> > capability to load shared objects by name.
> > The freebsd libc provides an fdlopen function (See:
> > https://www.freebsd.org/cgi/man.cgi?query=fdlopen&sektion=3), which
> allows
> > you to open a shared object from a file descriptor. This has numerous
> > benefits, including the fact that you can test properties on the file
> > descriptor before loading it as a shared object (for example, you can
> > validate some signature on the shared object, or, in a privileged
> process,
> > check the file permissions to see if its owned by root + suid). Using
> > simply dlopen, a program cannot securely do this, as attempts to do so
> > would be vulnerable to TOCTOU exploits. (On linux systems with the /proc
> > filesystem, it is possible to write code that solves this, however it is
> > entirely a hack.)
> > I was wondering if there was a reason why glibc does not provide similar
> > functionality (even behind #define _BSD_SOURCE). It would likely be less
> > hacky than using the proc filesystem (and less prone to
> open("/proc",F_OK)
> > -> EACCESS/ENOENT).
>
> There is no strong reason why we don't have fdlopen(). I'd like to see it
> implemented. If someone wants to work on it that would be great.
>
> I would also like to see something like dlopen_from() implemented per this
> discussion:
> https://sourceware.org/pipermail/libc-help/2020-January/005107.html
>
> --
> Cheers,
> Carlos.
>
>

Re: libdl, no fdlopen function

[Carlos O'Donell]

On 7/22/20 10:42 PM, connor horman wrote:
> I can look into implementing it. Having it available would be quite useful
> as I want to do runtime dso signature verification. I'd have to look at the
> code that deals with the actual runtime loading and see where the name gets
> turned into a file descriptor.

You'd be looking at _dl_map_object, which once it finds the object opens the
fd and then calls _dl_map_object_from_fd.

If I had to hack something up I'd write a thin wrapper around _dl_map_object_from_fd
and then add some tests and see if I could get to work with that.

You'd have to review _dl_map_object to see all of the things you'd have to consider
as consequences e.g. What if you load the same object twice? Auditors?

Please also look through this:
https://sourceware.org/glibc/wiki/Contribution%20checklist

-- 
Cheers,
Carlos.