Bug 1150554 - AUDIT-1: sarg: review of cron job file(s): /etc/cron.daily/suse.de-sarg, /etc/cron.monthly/suse.de-sarg, /etc/cron.weekly/suse.de-sarg
AUDIT-1: sarg: review of cron job file(s): /etc/cron.daily/suse.de-sarg, /etc...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Thomas Abraham
E-mail List
:
Depends on: CVE-2019-18932
Blocks: 1150175
  Show dependency treegraph
 
Reported: 2019-09-12 12:04 UTC by Matthias Gerstner
Modified: 2020-04-01 13:37 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 12:04:17 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.

sarg installs the following cron files:

- /etc/cron.daily/suse.de-sarg
- /etc/cron.monthly/suse.de-sarg
- /etc/cron.weekly/suse.de-sarg

They should be reviewed and whitelisted when all is well.
Comment 1 Matthias Gerstner 2019-11-13 11:22:26 UTC
The good news is: Those cron jobs don't act by default, only if explicitly
enabled in /etc/sysconfig/sarg.

The bad news is: If this sarg program actually runs then there are a lot of
worries regarding handling of temporary files. Both the sarg-report script and
the C program sarg use questionable temporary file handling.

Especially the sarg C program uses the fixed directory /tmp/sarg by default
and a lot of racy system calls to create the dir and files within the dir.
This allows at a minimum local users to place symlinks in there and corrupt
system files. Arbitrary code execution should be not included but I can't
fully say. This is also worty a CVE assignment.

The purpose of sarg is to scan the squid access.log logfile and generate a
report from it. This task could possibly also be fullfilled without root
privileges e.g. running as the squid user. This would make things a lot safer
and robust.

The upstream project is pretty inactive. Only once minor release in 2018, the
one before was in 2015.

Given all the circumstances this might even be a candidate for removal from
openSUSE. Code quality certainly is not good!
Comment 3 Matthias Gerstner 2020-01-30 10:59:29 UTC
Still waiting for bug 1156643 to be fixed in Factory before a whitelisting can
be made.
Comment 4 Matthias Gerstner 2020-02-27 13:40:07 UTC
I still wanted to harden the way sarg is executed. The upstream author
confirmed to me that the squid user is sufficient to run sarg. Therefore I'd
like the merged and adjusted cron job script from attachment 824051 [details] to be used
before I whitelist this cron job.

I created a submission sr#779928 that does this.
Comment 5 Matthias Gerstner 2020-02-28 09:48:09 UTC
I have replaced the submission by sr#780202 in the meantime. In the original
approach only the cron job dropped privileges. But this could have caused
additional security issues when somebody calls sarg-reports a different way
(e.g. manually on the command line).

Therefore I've moved the privilege drop code into the sarg-reports script
itself. It now drops privilege to the owner:group of the /srv/www/sarg
directory. This also allows users to easily restore the original behaviour
with sarg running as root, if desired for some reason.
Comment 6 Matthias Gerstner 2020-03-04 10:13:37 UTC
My submit request from comment 5 was accepted by now and I also submitted a
whitelisting for the new cron job files and the privilege drop code. Therefore
we can close this bug as FIXED.
Comment 7 Thomas Abraham 2020-03-27 15:59:28 UTC
I got an email about sarg build failing in factory since March 19th. I'm assuming that they haven't been whitelisted yet? Log shows:


[   30s] sarg.x86_64: E: cronjob-changed-file (Badness: 10000) /etc/cron.daily/suse.de-sarg
[   30s] sarg.x86_64: E: cronjob-changed-file (Badness: 10000) /etc/cron.monthly/suse.de-sarg
[   30s] sarg.x86_64: E: cronjob-changed-file (Badness: 10000) /etc/cron.weekly/suse.de-sarg
[   30s] A cron job or cron job related file installed by this package changed
[   30s] in content. Please open a bug report to request follow-up review of the
[   30s] introduced changes by the security team. Please refer to
[   30s] https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for
[   30s] more             information.
[   30s] 
[   30s] (none): E: badness 30000 exceeds threshold 1000, aborting.
Comment 8 Malte Kraus 2020-03-27 17:27:24 UTC
There's a whitelisting in place, but something about it is broken. I've opened https://github.com/openSUSE/rpmlint-security-whitelistings/issues/5 to track this.
Comment 9 Matthias Gerstner 2020-04-01 13:37:35 UTC
A fix is on the way via sr#790150 to Factory.

Sorry for the inconvenience, turned out test coverage was still not high
enough for the new rpmlint-check.