Bug 1206838
| Summary: | zarafa: default permission issue | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Robert Scheck <redhat-bugzilla> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | unspecified | CC: | security-response-team | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-03-24 23:25:48 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
https://download.zarafa.com/community/final/7.2/7.2.0-48204/sourcecode/ is the upstream tarball my patch proposal is meant for. Looking to older versions (zarafa-search-plus using python and xapian is a rewrite of zarafa-search using kyotocabinet and clucene which is again a rewrite of zarafa-indexer using clucene): Zarafa 7.1.x: zarafa-search creates /var/lib/zarafa/index/ (= index_path) with root:root or zarafa:zarafa (depending on the user zarafa-indexer is started with) and 700. But files under <index_path> are created are world- readable. I didn't figure out how to dump a kyotocabinet database (to see what's in). Zarafa 7.0.x and 6.40.x: zarafa-indexer creates /var/lib/zarafa/index/ (= index_path) with root:root or zarafa:zarafa (depending on the user zarafa-indexer is started with) and 700. But files and directories under <index_path>/<server>/<user>/ created are world-readable and these files contain sensitive data (verified using strings(1)). Acknowledgements: Red Hat would like to thank Robert Scheck for reporting this issue. This issue is public: https://forums.zarafa.com/showthread.php?11304-Zarafa-7-2-Problems-Bugs-with-the-new-search Kurt, thank you for pointing out this. I wasn't aware about this posting; but doesn't really explain why upstream didn't reply to Ticket#2015033110001675 so far (which also included the patch). CVE request: http://seclists.org/oss-sec/2015/q2/90 The issue only affects zarafa-search >= 7.2 (not in EPEL), not zarafa-search < 7.2 (in EPEL). |
Created attachment 1007828 [details] Patch suggestion which adds a more restrictive umask I discovered an issue in zarafa-search (being part of Zarafa >= 7.2.0), which is that the daemon creates the directory /var/lib/zarafa/search/ with the permissions root:root and 777 (read- and writable for world), if the directory does not already exist. Subsequently all files inside of /var/lib/zarafa/search/ created by the zarafa-search daemon are also read- and writable for world (independent of the permissions of parent directory). /var/lib/zarafa/search/ is the default directory according to index_path setting in /etc/zarafa/search.cfg. Depending on the packaging this issue might be mitigated (e.g. parent directory with zarafa:zarafa and 750). However the index_path value can be changed by an administrator and just relying on a packaging that might mitigate the issue isn't IMHO correct. Inside of /var/lib/zarafa/search/ the index (created via xapian) of the Zarafa content is stored, thus the index files contain words and phrases from e-mails, contacts, calendar entries etc. /usr/lib*/python2.?/site-packages/zarafa/daemon/daemon.py is where the wrong permission comes from. But the same file also states the behaviour; the mentioned file itself is copied by Zarafa from python-daemon: `umask` :Default: ``0`` File access creation mask (“umask”) to set for the process on daemon start. Since a process inherits its umask from its parent process, starting the daemon will reset the umask to this value so that files are created by the daemon with access modes as it expects. While above might leave some space if the origin is within Zarafa or the python-daemon the following is IMHO much more clear. Note that the (above) bundled python-daemon is 1.6 while the following is from 2.0.5: `umask` :Default: ``0`` File access creation mask (“umask”) to set for the process on daemon start. A daemon should not rely on the parent process's umask value, which is beyond its control and may prevent creating a file with the required access mode. So when the daemon context opens, the umask is set to an explicit known value. If the conventional value of 0 is too open, consider setting a value such as 0o022, 0o027, 0o077, or another specific value. Otherwise, ensure the daemon creates every file with an explicit access mode for the purpose. So the issue is IMHO that the zarafa-search daemon does not set the correct umask before calling python-daemon's DaemonContext().