Bugzilla – 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
Last modified: 2020-04-01 13:37:35 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.
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!
Still waiting for bug 1156643 to be fixed in Factory before a whitelisting can be made.
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.
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.
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.
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.
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.
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.