[Aide] static linking on Linux and Packaging for Distributions

Marc Haber mh+aide at zugschlus.de
Sat Sep 11 17:17:33 EEST 2021


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


More information about the Aide mailing list