Bug 14780 - Private libraries are injected into system applications
Summary: Private libraries are injected into system applications
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 4.15.0rc1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Stefan Metzmacher
QA Contact: Samba QA Contact
URL: https://gitlab.com/samba-team/samba/-...
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-03 18:54 UTC by Stefan Metzmacher
Modified: 2021-11-30 18:35 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Metzmacher 2021-08-03 18:54:31 UTC
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.

One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g. ldd /usr/lib64/sssd/libsss_ad.so| grep samba
   libsamba-util.so.0 => /lib64/libsamba-util.so.0
   libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
   libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
   libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
   libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
   libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
   libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
   libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
   libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
   libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so

When that loads dlopen() will fail as a soname libreplace-samba4.so is already
loaded, but the symbol version within the other one don't match, as the contain
the exact version, e.g. replace_dummy@@SAMBA_4.13.3.

This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.

We have the following libraries, which are in the that category:

- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so

The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.

In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.

   bld.SAMBA_SUBSYSTEM('replace-hidden',
                       source=REPLACE_SOURCE,
                       group='base_libraries',
                       hide_symbols=True,
                       deps='dl attr' + extra_libs)

It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so

But 'async_dns_krb5_locator.so' links in almost everything!
And the krb5 plugins are always loaded without any configuration,
every .so in a special pass are loaded with dlopen(), by every
application using kerberos, so we load a lot of samba libraries
into them.

I think we should disable async_dns_krb5_locator.so by default,
or at least install it into a path that's not reachable by
libkrb5.so. But it would still allow the admin to create a
symlink to activate it. As a longterm solution we may want
to change async_dns_krb5_locator.so to use a helper process
with posix_spawn() instead of doing everything within the process.
Comment 1 Samba QA Contact 2021-11-30 16:45:04 UTC
This bug was referenced in samba master:

03cd1449f697dc7a9950fd4d333273ea72bcb174
893c24605a5874b4b093ea1967ebbcb1e4837ffa
932c408c1b4f53098c8857941bcaf67c978195ec
d6749f590f338cff42634c7406dda96dc1d8e2fd
43b90da1867135ddb5f740c9d664af4c2d96a18f
da7c41e26016845f0dfd78601987c075ef8711a6
33e6949dda83996550d126d7de09a13691ff35cc
3aff74e29ed3bb99fd7b9a510001e7046b86c8fa
295e5270f60296feb4e9bbb57ae3b3f58f2d3258
38ef29bc219afcd608a1c87f8aae99cebe79b665
70da83a8ca7fdb2d1bcd8601a1a0111d39469000
38d37d4a53285f08ce805f28b0659456c197f023
f168f548784e643335cf0351a5f506dbc087f65f
e35f23195f921f48b78dfe9cc1d0f85194697ece
6c64f3cee832c9f48b3cc058d3de31561524997a
c461b906ca5940bcf69901f973b5698e3ef75063
600ebefa5af806f376abda722fb492895f0603ac
35446c27f8ef3532d2440d4e86774e13065e86c4
ac8977d1e760824d9f170455899e53aa555f807e
f3c5980f76f30c65378623e4f5b25e73d4ace25b
41108b9ed9f32ca9ad1b3d4a48a91a6f22c65db6
9615395b1fdaa4509a9739bada93c3bb72903b2c
a663c9648f14294d7e02f30ee1a9a53b1a404279
3f9948bd6dc16e7cf488277fab6837f545e94432
419ca68de0c9ed02612e64717963d133833061e7
fa98a44cb4d94c6a290deb931b260e411364314d
62d05a81087029d93ba0cf81c11e5b244d788aef
05ca7b9809d7329aea93fc8f1b8b2e54703f1dbd
66e90b7391bd404580f3919c4f2b8625c9c89c0e
4862a8ff2f02cf7c735d666520846f6a0d63c6b0
6745968a15497c88646c1213ec6a8b198e624abb
Comment 2 Stefan Metzmacher 2021-11-30 18:35:17 UTC
This will be fixed in 4.16, people can backport this into private
trees as needed, but I'm not sure it's a good idea to change names of
private libraries in 4.15.x...