Bug 1150548 - AUDIT-1: matomo: review of cron job file(s): /etc/cron.d/matomo-archive
AUDIT-1: matomo: review of cron job file(s): /etc/cron.d/matomo-archive
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Johannes Segitz
E-mail List
:
Depends on:
Blocks: 1150175
  Show dependency treegraph
 
Reported: 2019-09-12 11:58 UTC by Matthias Gerstner
Modified: 2020-03-12 09:46 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2019-09-12 11:58:07 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.
Comment 1 Eric Schirra 2019-09-12 13:06:08 UTC
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.
Comment 2 Matthias Gerstner 2019-09-12 13:16:16 UTC
(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.
Comment 3 Eric Schirra 2019-09-12 14:44:59 UTC
(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. :-)
Comment 4 Matthias Gerstner 2019-11-07 13:03:03 UTC
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.
Comment 5 Matthias Gerstner 2020-02-28 11:56:24 UTC
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.
Comment 6 Johannes Segitz 2020-03-05 08:35:55 UTC
(In reply to Matthias Gerstner from comment #5)
I will have a look on this today
Comment 7 Johannes Segitz 2020-03-12 09:46:40 UTC
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