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
