[Aide] [EXT] static linking on Linux and Packaging for Distributions

[David V Duccini]

Option 2 makes the most sense IMHO since there are other tools / mitigations to detect this including snapshots and jails

For the truly paranoid AIDE could build a hash of all its dependencies and have a human digitally sign off on it using PGP/GPG — something like this would have general utility beyond AIDE...

-dvd

> On Sep 11, 2021, at 09:17, Marc Haber <mh+aide at zugschlus.de> wrote:
> 
> 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 Debian 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 more than 15
> years, so it would be a realistic thing to just continue ignoring it and
> doing a rebuild when an incompatible glibc version comes along
> 
> (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 without making
> it necessary to manually write the libc version into deban/control.
> 
> (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.
> 
> 
> Do people on this list have additional ideas? I have filed Issue #109 in
> github to make Upstream aware of this, and I'm going to post a similiar
> message to Debian-mentors to get the opinion of other Debian people.
> 
> 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
> _______________________________________________
> Aide mailing list
> Aide at ipi.fi
> https://www.ipi.fi/mailman/listinfo/aide