From mh+aide at zugschlus.de Sat Sep 11 17:17:33 2021 From: mh+aide at zugschlus.de (Marc Haber) Date: Sat, 11 Sep 2021 16:17:33 +0200 Subject: [Aide] static linking on Linux and Packaging for Distributions Message-ID: 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 From david at backpack.com Sat Sep 11 17:28:07 2021 From: david at backpack.com (David V Duccini) Date: Sat, 11 Sep 2021 09:28:07 -0500 Subject: [Aide] [EXT] static linking on Linux and Packaging for Distributions In-Reply-To: References: Message-ID: <93C73C57-A3E0-4E68-8034-16CD7FBFF293@backpack.com> 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 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