[SERVER-15068] Processes that read sensitive files should be able to change user after reading/opening said files Created: 28/Aug/14 Updated: 21/Aug/15 Resolved: 19/Aug/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 2.6.3, 2.7.5 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Andrew Ryder (Inactive) | Assignee: | Andreas Nilsson |
| Resolution: | Won't Fix | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
It should be possible to configure processes like mongod and mongos, which sometimes need to read sensitive files like PEM and key files, to change the user they're running as after reading those files. If it is intended that mongod/mongos be able to run on privileged ports then binding to those ports should also happen before changing user. The use case would be to allow sensitive files to be owned by root, start these processes as root, but then have them quickly change to running as an unprivileged user (e.g. mongodb) after reading the sensitive files or performing other privileged operations. Of particular interest would be the following files configurable through the command-line:
We can't protect against in-memory access, but we can still up the bar and make grabbing the secrets require the more sophisticated skill of accessing and decoding RAM rather than just using cat the key for cracking offline. Increasing security by requiring different skillsets to pull off an attack can be an effective technique. For example, the guy who knows how to exploit V8 and JavaScript would likely find it easy to then issue shell commands and use an offline cracking tool, but is less likely to know how to access and then decode RAM. |
| Comments |
| Comment by Timothy Olsen (Inactive) [ 20/Aug/15 ] |
|
The automation agent will use the cluster auth PEM file (passed via --sslClusterFile) for authenticating to mongod and mongos processes when cluster auth is being used. It currently does not use the PEM file passed via --sslPEMKeyFile (and there are no plans to do so). |
| Comment by Ramon Fernandez Marina [ 19/Aug/15 ] |
|
I just realized that to implement this feature as described the following condition must hold: sensitive files must be read by mongod/mongos only at startup, and never during normal operation. It seems that mongod does satisfy this condition, but this requirement may not have been part of the original design so I can't assert that this behavior is intended. Same thing for mongos. Let's suppose for a moment that this condition is true, and these files are only read at startup. In this case a potential workaround would be to make these sensitive files available to mongod/mongos before startup via init scripts run with elevated privileges. After startup, these files can be made unavailable again (e.g.: via chmod) – this should address the security concerns raised in this ticket's description. It's worth noting that the Automation Agent may need access to some of these files as well to authenticate to clusters, so either implementing the feature requested in this ticket or the workaround described above would need to take into account the Agent as well. Regards, |
| Comment by Ramon Fernandez Marina [ 19/Aug/15 ] |
|
Apologies for the long delay in following up here. This request requires mongod and mongos to be able to run with superuser privileges for the sole purpose of accessing specific files and running on privileged ports. This adds a lot of complexity and may open the door to security-related problems (as sendmail's history can show). In the case of sensitive files, they can be owned by the mongod user and secured with the right permissions. That leaves the case of running on a privileged port, which we don't believe is a compelling use case. I'm therefore going to close this ticket. If a strong case is put forth to add this functionality we can always re-open this ticket and discuss options. Regards, |