static linking, libc and handling this in the aide package
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 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 in more than 15
years, so it would be a realistic thing to just continue ignoring it and
requesting a binNMU when an incompatible glibc version comes along and
aide stops working on unstable.
(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 or whether it
would be necessary to keep the versioned Depends manually up to date.
(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.
What would debian-mentors' recommendation be? Your hints will be
appreciated.
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
Reply to: