Bugzilla – Bug 1150549
AUDIT-1: munin: review of cron job file(s): /etc/cron.d/munin
Last modified: 2019-12-05 11:09:10 UTC
+++ This bug was initially created as a clone of Bug #1150175 As discussed in the proactive security team we want to restrict the installation of cron job files in the future. To achieve this we first need to cover the currently existing packages that do this. munin installs a cron file in /etc/cron.d/munin. It should be reviewed and whitelisted if all is well.
There is currently work in progress to move to a systemd timer. It is mainly blocked on the fact that the upgrade process is somewhat complicated. At least I'm not sure how to cover this nicely. (That's another topic though). So what is the plan according to systemd timers? Would this one be obsolete in case we move?
(In reply to wolfgang@rosenauer.org from comment #1) > So what is the plan according to systemd timers? Would this one be obsolete > in case we move? At the moment we only want to cover cron jobs. systemd timers should currently be subject to reviews only when they're enabled by default. Technically we care only for cron jobs currently found in packages in openSUSE:Factory. So if you remove yours it wouldn't be strictly necessary to handle it. It will still make sense to have a look in case older products are affected by a security issue. We will need some time to process all the reviews for cron jobs anyways. Don't worry, we will tell you when there's a problem and at the moment we don't apply any restrictions.
In Tumbleweed the cron job is indeed gone now. I've looked into Leap 15.1 where the cron job still exists. It calls a couple of munin perl scripts that process pretty complex logic, too much too completely review it. The good thing is that the cron job runs as the 'munin' user and all file system operation seem to concentrate on directories owned by munin. I couldn't find any /tmp races, symlink attacks or similar right away.
Since the Factory package no longer ships the cron job and the older codestreams look sufficiently sane we can close this bug. No whitelisting will be necessary.