search

sbidy / MacroMilter

This python based milter (mail-filter) checks an incoming mail for suspicious VBA macro code in MS 20xx Office attachments (doc, xls, ppt ...).
MIT License
37 stars 14 forks source link

Local information leak via log files #18

Closed robert-scheck closed 6 years ago

robert-scheck commented 6 years ago

If LOGFILE_DIR does not exist, it's created with the default umask, thus world readable. Additionally, the log file itself, LOGFILE_PATH, is also created world readable. From my point of view, this leads to a local information leak, because some e-mail metadata information are readable for unprivileged local users (attachment file names, envelope sender), while such e-mail metadata information are normally not disclosed to unprivileged users via /var/log/maillog (or similar).

While replacing os.makedirs(LOGFILE_DIR) by os.makedirs(LOGFILE_DIR, 0750) likely does the trick, I did not find something suitable for logging.handlers.TimedRotatingFileHandler(), just others with the same issue: https://stackoverflow.com/questions/1407474/does-python-logging-handlers-rotatingfilehandler-allow-creation-of-a-group-writa

Note: The information leak might be partially or totally mitigated by logrotate, but I am so far unable to see whether logging.handlers.TimedRotatingFileHandler() or logrotate finally rotates the log files, but that's #17 and thus outside of this scope.

Currently unused constant ARCHIVE_DIR as well archive_message() method are suffering the same local information leak issue.

sbidy commented 6 years ago

Link with #17

sbidy commented 6 years ago

I have to update the log behavior in general. That's correct, the log file should be only readable for root users and the macromilter demon. I try to fix the information leak ASAP with the global umask in 3.4.4.

A enhanced function rewrite comes with the 3.5.

sbidy commented 6 years ago

Done - enhancement via 3.5