Potentially existing (legitimate, root owned) lock file getting deleted by Apport daily cron(8) script

Author: Sander Bos, <https://www.sbosnet.nl/>

Date: 2019-07-30

As an unintended side effect of removing old crash reports,
Apport's etc/cron.daily/apport daily cron(8) job file also deletes
the /var/crash/.lock file, a lock file which Apport normally creates
(as root) when it first runs:

      4 find /var/crash/. ! -name . -prune -type f \( \( -size 0 -a \! -name '*.upload*' -a \! -name '*.drkonqi*' \) -o -mtime +7 \) -exec rm -f -- '{}' \;

The /var/crash/.lock lock file not already existing, i.e., Apport not
having run yet, is a precondition for a different issue (the issue of
/var/crash/.lock being fully user controllable due to it being placed
in a world-writable directory) to get exploited. However, removing the
file on a daily basis means that precondition is then met, even if the
lock file existed beforehand. This means exploit possibilities for that
other issue are opened up again on a daily basis, even when a legitimate
lock file was previously present.

On a side note: issues might or might not arise in case the lock file
happens to get deleted during a run of Apport, i.e., when Apport is using
it or having set a lock on it. This might or might not especially apply
in combination with the "30 seconds timeout" code in check_lock().

Proposed fix: exclude the lock file from being deleted by the daily
cron(8) job (but note that there may also be other packages cleaning up
/var/crash/, potentially not excluding the lock file) from being deleted.