Hi,

aide is traditionally linked statically to protect itself against
trojaned / doctored libraries that might affect the authenticity of the database and the check results. On Linux, this has not been fully
effective for years since some dynamicity remains, especially regarding
NSS.

During Debian's last glibc transition, this has led to reproducible and unconditional segfaults once aide uses a nss call, which happens via
libacl when a file possessing an ACL is processed during check.

As the maintainer of the package, I am pondering about what to do with
the package in the future. We have the following possibilities:

(1)
Keep things as they are. This issue has surfaced once in more than 15
years, so it would be a realistic thing to just continue ignoring it and requesting a binNMU when an incompatible glibc version comes along and
aide stops working on unstable.

(1a)
At the moment we have the ugly situation that the statically linked
package doesn't have a binary depends on any glibc package, so apt will
happily install the incompatible version and have it segfault. I would
like to have aide have an appropriate dependency on the glibc packages
so avoid this, but, IMO, this would make it unnecessarily necessary to
upload new aide for new glibc versions. Also I don't know whether it
would be possible to automatically create the dependency or whether it
would be necessary to keep the versioned Depends manually up to date.

(2)
Make the default aide a dynamically linked version. This would bring us
all Debian magic of automatically generated dependencies, automatic
binNMUs during libc transitions etc. The statically linked package
version wold either be ditched or moved to aide-static (retaining all
problems we currently have, giving us as a side-effect information about
how many people are still using the static version by seeing their bug reports). We are already vulnerable to trojaned / doctored dynmic NSS
library and of course to a doctored / trojaned aide binary, so the
saved exposure is of a rather acedemic level.

(3)
Link aide statically to a different libc that doesnt have the
semi-dynamic issues of NSS. I don't have a remote clue about how to do
that and how this would affect pulling in existing libs such as libacl
which are already dynamically linked against glibc. If we'd need special version of all our libraries linked against the alternative libc
version, then actually doing this for Debian is totally out of the
question.

What would debian-mentors' recommendation be? Your hints will be
appreciated.

Greetings
Marc


-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Sep 11, 2021 at 2:26 PM Marc Haber wrote:

What would debian-mentors' recommendation be? Your hints will be
appreciated.

To prevent installation of an static aide with a incompatible nss
libraries, you could get glibc to add Provides: libc-nss-abi (= N) or
Provides: libc-nss-abi-N and a mechanism to get the current ABI number
at build time then have aide depend on that. Then when glibc
transitions happen, aide could get binNMUed automatically.

I wondering which nss calls aide is doing and if they can be
eliminated entirely.

I think I would lean towards the dynamic solution; I assume that if
someone can modify the nss libraries then they can also modify the
static aide binaries.

It might be worth discussing the issue with aide upstream, they
probably have guidance about this by now.

PS: I wonder if you are tracking when static aide requires a binNMU
after security updates to libraries it uses?

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)