posted 2022-09-21
The post-install routine for the Gentoo app-admin/logcheck package
runs chown -R logcheck:logcheck
on
/var/lib/logcheck. If the package is ever
reinstalled, the logcheck user can place a hardlink in that directory
that exploits the chown to take ownership
of sensitive files. A similar vulnerability exists in the package's
(Gentoo-specific) cron job.
The ebuild for logcheck creates the /var/lib/logcheck directory at install-time, but then uses the post-install phase to “correct” its ownership:
src_install() {
...
keepdir /var/lib/logcheck
...
}
pkg_postinst() {
chown -R logcheck:logcheck /etc/logcheck /var/lib/logcheck || die
readme.gentoo_print_elog
}
This is safe the first time the package is installed, since /var/lib/logcheck will still be owned by root when chown is called. But if the package is ever reinstalled, the recursive chown will affect any files under /var/lib/logcheck that the logcheck user has created in the meantime. In particular, the logcheck user can exploit the situation by creating hardlinks to sensitive files, because the recursive call to chown will affect the target of any such link. This is an instance of the problem described in the article End root chowning now (make pkg_postinst great again).
A similar problem exists in the Gentoo-specific cron job that app-admin/logcheck installs,
#!/bin/bash
set -e
if [ ! -d /var/lock/logcheck ]; then
mkdir -p /var/lock/logcheck
fi
chown -R logcheck:logcheck /var/lock/logcheck
su -s /bin/bash -c /usr/sbin/logcheck logcheck
It was likely intended that the chown be executed only once, after the first successful mkdir. Credit for spotting this goes to Manuel Rüger.
The app-admin/logcheck package (and its cron job) have been removed from Gentoo.