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 <[email protected]> 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 > [email protected] > https://www.ipi.fi/mailman/listinfo/aide _______________________________________________ Aide mailing list [email protected] https://www.ipi.fi/mailman/listinfo/aide
