Bugzilla – Bug 1150548
AUDIT-1: matomo: review of cron job file(s): /etc/cron.d/matomo-archive
Last modified: 2020-03-12 09:46:40 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. matomo installs a cron file in /etc/cron.d/matomo-archive. It should be reviewed and whitelisted if all is well.
I don't want delete the file in package. I use not systemd and i want not use systemd. And i think many other people also. The package have cron and systemd.timer. So, anybody can use what he/she want. What's the problem? Security risk? Why? PS: Have no rights for Bug #1150175.
(In reply to ecsos@schirra.net from comment #1) > I don't want delete the file in package. > I use not systemd and i want not use systemd. > And i think many other people also. > > The package have cron and systemd.timer. > So, anybody can use what he/she want. > What's the problem? > Security risk? Why? You don't need to worry. We don't want to delete the cron job. We only want to *review* it. When there's no security issue then everything is fine.
(In reply to Matthias Gerstner from comment #2) > (In reply to ecsos@schirra.net from comment #1) > > I don't want delete the file in package. > > I use not systemd and i want not use systemd. > > And i think many other people also. > > > > The package have cron and systemd.timer. > > So, anybody can use what he/she want. > > What's the problem? > > Security risk? Why? > > You don't need to worry. We don't want to delete the cron job. We only want > to > *review* it. When there's no security issue then everything is fine. OK. Then I am calmed down. :-)
So I've looked at this cron job. A PHP script is run as the `wwwrun` user. As usual the PHP program is not trivial but rather complex. At least I couldn't find any misuses of /tmp or access of untrusted files/data. It does interpret the output of `ps ex` at one point but since this listing only contains the own user's processes there shouldn't be any attacker surface. Luckily it's not running as root.
I'm now whitelisting this package's cron job since it passed the first review I conducted. I keep the bug open for Johannes to decide if he still wants to have a second look.
(In reply to Matthias Gerstner from comment #5) I will have a look on this today
So that took a little longer but I used the opportunity to improve some of the tools used for audits like these. I didn't find issues with the cron-job and the whitelist is present, so we should be done here