[Clamav-devel] dlopen using relative path for libclamunrar
Micah Snyder (micasnyd)
micasnyd at cisco.com
Wed Feb 24 17:00:08 UTC 2021
Hi Mark,
You're welcome!
Sure, please send a patch my way. I'd prefer if no one had to apply patches to use ClamAV, so getting those things working upstream is ideal.
-Micah
> -----Original Message-----
> From: clamav-devel <clamav-devel-bounces at lists.clamav.net> On Behalf Of
> Mark Allan
> Sent: Wednesday, February 24, 2021 7:22 AM
> To: ClamAV Development <clamav-devel at lists.clamav.net>
> Subject: Re: [Clamav-devel] dlopen using relative path for libclamunrar
>
> Hi Micah,
>
> Thanks so much. Prepending the install path PREFIX in the dlopen call works a
> dream!
>
> Trying the absolute path first is necessary to avoid macOS (with hardened
> runtime) printing that warning message every time the command is run. If
> that call fails, it reverts back to the original code which also allows tests to
> succeed.
>
> I can share a patch if you like, but it would be of limited use as I've just hard-
> coded the path seeing as my knowledge of Makefiles is limited and I don't
> know how to reference the PREFIX configure option from within others.c !
>
> Many thanks again for your help.
> Mark
>
> > On 24 Feb 2021, at 2:25 am, Micah Snyder (micasnyd)
> <micasnyd at cisco.com> wrote:
> >
> > The license stuff is tricky. I'm not a lawyer, so my advice is maybe not too
> helpful here. We include the UnRAR license with ClamAV, but I suppose
> could be more specific to say that UnRAR's restrictions on reverse
> engineering to create a RAR archiver apply to ClamAV if UnRAR is linked with
> ClamAV. That's how I would want to go about it, anyways. I guess maybe I
> need to ask a lawyer.
> >
> > The function that loads libclamurnar_iface is load_module() and is
> > invoked here:
> > https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.104/libclamav/o
> > thers.c#L314
> >
> > As you can see, there are two variants. The first uses libtool's LTDL to load
> it, the second (newer variant) doesn't. I added the 2nd variant to simplify
> the codebase when adding the CMake build system. Anyways... The original
> LTDL variant adds "SEARCH_LIBDIR" to the search path, which is the install
> path for the library. We _could_ just prefix name with the SEARCH_LIBDIR to
> give it an absolute path and that'd probably work if you install to a specific
> location and never move it, but it will cause the unit tests to fail any RAR-
> related tests. A second call to try using absolute path for the build directory
> for the library could be added in case the first failed and that'd get the build
> to work, though that would hadcode the build directory into the release
> materials which is poor form.
> >
> > Pending anything more official about the whole static-linking thing with
> UnRAR, I don't have a great answer.
> >
> > -Micah
> >
> >> -----Original Message-----
> >> From: clamav-devel <clamav-devel-bounces at lists.clamav.net> On Behalf
> >> Of Mark Allan
> >> Sent: Tuesday, February 23, 2021 4:33 PM
> >> To: ClamAV Development <clamav-devel at lists.clamav.net>
> >> Subject: Re: [Clamav-devel] dlopen using relative path for
> >> libclamunrar
> >>
> >> Hi Micah,
> >>
> >> Many thanks for your reply. I'm always careful to abide by software
> >> licences, so wouldn't want to build as 'static' if that would be against
> UnRAR's licence.
> >>
> >> I'm really just looking for a way to make dlopen load
> >> libclamunrar_iface (and all/any other libraries) by way of absolute
> >> paths instead of relative ones, without building as static. Is that at all
> possible?
> >>
> >> Thanks again,
> >> Mark
> >>
> >>> On 23 Feb 2021, at 11:57 pm, Micah Snyder (micasnyd)
> >> <micasnyd at cisco.com> wrote:
> >>>
> >>> Hi Mark,
> >>>
> >>> libclamunrar_iface is loaded dynamically with dlopen and is not
> >>> linked with libclamav. UnRAR's license is not entirely "free". It
> >>> restricts against reversing UnRAR to create a RAR archiver. This
> >>> predates me, but my understanding is this: The intention is to
> >>> separate libclamav's
> >>> GPLv2 source so that ClamAV can be distributed by Debian on normal
> >>> (free software) package servers. Debian distributes the libclamunrar
> >>> library separately. In this way, ClamAV installed from Debian's
> >>> `apt-get clamav` can function without RAR support but if RAR support
> >>> is desired and the user is okay with using "non-free" software, they
> >>> can enable the non-free packages and install libclamunrar. Eg:
> >>> https://www.danami.com/clients/knowledgebase/90/How-can-I-
> enable-
> >> .rar-
> >>> support-for-ClamAV.html
> >>>
> >>> Of course, if you're building ClamAV for macOS and you have no
> >>> qualms
> >> about the free/non-free open source licensing, then perhaps linking
> >> libclamunrar_iface with libclamav is the way to go. This isn't simple
> >> in the build system at present but as soon as I merge this work
> >> (https://github.com/micahsnyder/clamav-devel/tree/CLAM-34-unit-test-
> >> overhaul-windows-support), it will be as simple as doing a CMake
> >> build with static enabled and shared disabled:
> >> https://github.com/micahsnyder/clamav-devel/blob/CLAM-34-unit-test-
> >> overhaul-windows-support/CMakeLists.txt#L140 I added this capability
> >> for better code coverage in oss-fuzz, but I imagine it will be good
> >> for macOS hardened systems as well.
> >>>
> >>> On that note, CMake's CPack tool may be used to build installers for
> >> Windows AND build package installers for macOS as well. Publishing
> >> Windows installers is something I needed to do for feature parity
> >> with our old build system, but it's on my to-do list to do the same
> >> for macOS, and to add it into our internal Jenkins CI pipeline. I
> >> suppose I should consider making at least the macOS one static.
> >>>
> >>> -Micah
> >>>
> >>>> -----Original Message-----
> >>>> From: clamav-devel <clamav-devel-bounces at lists.clamav.net> On
> >>>> Behalf Of Mark Allan
> >>>> Sent: Saturday, February 20, 2021 4:43 PM
> >>>> To: ClamAV Development <clamav-devel at lists.clamav.net>
> >>>> Subject: [Clamav-devel] dlopen using relative path for libclamunrar
> >>>>
> >>>> Hi there,
> >>>>
> >>>> Ever since enabling the macOS hardened runtime for ClamAV, I've
> >>>> been getting the following error/warning message whenever I try to
> >>>> call any of the ClamAV
> >>>> binaries:
> >>>>
> >>>>> LibClamAV Warning: Cannot dlopen libclamunrar_iface:
> >>>> dlopen(libclamunrar_iface.a, 2): no suitable image found. Did find:
> >>>>> file system relative paths not allowed in hardened programs -
> >>>>> unrar
> >>>> support unavailable
> >>>>
> >>>>
> >>>> Is there any reason why the libclamunrar library would be being
> >>>> referenced via relative path instead of absolute, and is there any
> >>>> way I
> >> can fix this?
> >>>>
> >>>> The other libraries such as libclamav, libclammspack etc appear to
> >>>> load
> >> fine.
> >>>>
> >>>> I'd appreciate any help you can give.
> >>>>
> >>>> Thanks
> >>>> Mark
> >>>> _______________________________________________
> >>>>
> >>>> clamav-devel mailing list
> >>>> clamav-devel at lists.clamav.net
> >>>> https://lists.clamav.net/mailman/listinfo/clamav-devel
> >>>>
> >>>> Please submit your patches to our Github: https://github.com/Cisco-
> >>>> Talos/clamav-devel/pulls
> >>>>
> >>>> Help us build a comprehensive ClamAV guide:
> >>>> https://github.com/vrtadmin/clamav-faq
> >>>>
> >>>> http://www.clamav.net/contact.html#ml
> >>> _______________________________________________
> >>>
> >>> clamav-devel mailing list
> >>> clamav-devel at lists.clamav.net
> >>> https://lists.clamav.net/mailman/listinfo/clamav-devel
> >>>
> >>> Please submit your patches to our Github:
> >>> https://github.com/Cisco-Talos/clamav-devel/pulls
> >>>
> >>> Help us build a comprehensive ClamAV guide:
> >>> https://github.com/vrtadmin/clamav-faq
> >>>
> >>> http://www.clamav.net/contact.html#ml
> >>
> >> _______________________________________________
> >>
> >> clamav-devel mailing list
> >> clamav-devel at lists.clamav.net
> >> https://lists.clamav.net/mailman/listinfo/clamav-devel
> >>
> >> Please submit your patches to our Github: https://github.com/Cisco-
> >> Talos/clamav-devel/pulls
> >>
> >> Help us build a comprehensive ClamAV guide:
> >> https://github.com/vrtadmin/clamav-faq
> >>
> >> http://www.clamav.net/contact.html#ml
> > _______________________________________________
> >
> > clamav-devel mailing list
> > clamav-devel at lists.clamav.net
> > https://lists.clamav.net/mailman/listinfo/clamav-devel
> >
> > Please submit your patches to our Github:
> > https://github.com/Cisco-Talos/clamav-devel/pulls
> >
> > Help us build a comprehensive ClamAV guide:
> > https://github.com/vrtadmin/clamav-faq
> >
> > http://www.clamav.net/contact.html#ml
>
> _______________________________________________
>
> clamav-devel mailing list
> clamav-devel at lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
>
> Please submit your patches to our Github: https://github.com/Cisco-
> Talos/clamav-devel/pulls
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
More information about the clamav-devel
mailing list