[SERVER-31550] Cannot disable secure allocation domains for the shell Created: 13/Oct/17  Updated: 08/Jan/24  Resolved: 06/Dec/18

Status: Closed
Project: Core Server
Component/s: Security, Shell
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Sara Golemon
Resolution: Duplicate Votes: 1
Labels: platforms_security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-36807 Add setShellParameter to shell Closed
Problem/Incident
Operating System: ALL
Steps To Reproduce:

Apply the following patch:

diff --git a/src/mongo/base/secure_allocator.cpp b/src/mongo/base/secure_allocator.cpp
index 68f8c19023..827c157ca9 100644
--- a/src/mongo/base/secure_allocator.cpp
+++ b/src/mongo/base/secure_allocator.cpp
@@ -240,8 +240,10 @@ void* systemAllocate(std::size_t bytes) {
         fassertFailed(28831);
     }
 
-    if (mlock(ptr, bytes) != 0) {
+    if (true) { // mlock(ptr, bytes) != 0) {
+        errno = EPERM;
         auto str = errnoWithPrefix("Failed to mlock");

And then run the following test invocation:

buildscripts/resmoke.py --continueOnFailure --staggerJobs=on --reportFailureStatus=fail --dbpathPrefix=/tmp/db --mongodSetParameters='{disabledSecureAllocatorDomains: "*"}' --mongosSetParameters='{disabledSecureAllocatorDomains: "*"}' jstests/core/auth1.js

The shell will crash with an assertion, since it is still trying to use secure allocation.

Sprint: Platforms 2018-02-12, Security 2018-12-17
Participants:

 Description   

We can disable secure allocation when running the servers via the disabledSecureAllocationDomains setParameter. This is useful when running the servers on systems where the user does not have the appropriate capabilities to invoke mlock. However, there is no available mechanism to disable the secure allocator when running the shell, which renders it unusable on such systems.



 Comments   
Comment by Sara Golemon [ 06/Dec/18 ]

Somehow this got turned into a new ticket when we did the fix back in August.
In any event, `–setParameter disabledSecureAllocatorDomains=true` now works on the shell.

At the moment only that set parameter works on the shell.  We plan to revisit enabling other set parameters over time, but baby steps...

Comment by Gregory McKeon (Inactive) [ 23/Jul/18 ]

adam.cooper sync up with spencer.jackson before working on this more.

Comment by Michal Booth-Wrotkowski [X] [ 08/Feb/18 ]

That works! Thank you

Comment by Spencer Jackson [ 08/Feb/18 ]

Hi Booth-Wrotkowski, disabledSecureAllocatorDomains doesn't take '1' as an argument.

Can you try running your mongod with --setParameter=disabledSecureAllocatorDomains=*, possibly with escaping for the '*'?

Comment by Michal Booth-Wrotkowski [X] [ 07/Feb/18 ]

Andrew Morrow unfortunately it doesn't work for me. I'm using MongoDB 3.6.2 built from ports within jail on FreeBSD 11.1
I'm starting mongod command by:

/usr/local/bin/mongod --logpath /var/db/mongodb/mongod.log --logappend --config /usr/local/etc/mongodb.conf --dbpath /var/db/mongodb --setParameter=disabledSecureAllocatorDomains=1

Also when i check if disabledSecureAllocatorDomains is set correct by:

db.adminCommand( { getParameter : 1, "disabledSecureAllocatorDomains" : 1 } )

returns me:

{
    "disabledSecureAllocatorDomains" : [ 
        "1"
    ],
    "ok" : 1.0
}

But when I'm for example creating user with command

db.createUser(
   {
     user: "user",
     pwd: "password",
     roles: [ "readWrite", "dbAdmin" ]
   }
)

Mongo is crashing with error log:

2018-02-06T16:16:46.809+0000 F -        [conn16] Failed to mlock: Operation not permitted
2018-02-06T16:16:46.809+0000 F -        [conn16] Fatal Assertion 28832 at src/mongo/base/secure_allocator.cpp 246
2018-02-06T16:16:46.809+0000 F -        [conn16] 
 
***aborting after fassert() failure
 
 
2018-02-06T16:16:46.811+0000 F -        [conn16] Got signal: 6 (Abort trap).
 
 0x55e6516 0x55e5ff5 0x55e58aa 0x80939d926 0x80939cecf
----- BEGIN BACKTRACE -----
{"backtrace":[{"b":"1021000","o":"45C5516","s":"_ZN5mongo15printStackTraceERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEE"},{"b":"1021000","o":"45C4FF5","s":"_ZN5mongo15clearSignalMaskEv"},{"b":"1021000","o":"45C48AA","s":"_ZN5mongo29reportOutOfMemoryErrorAndExitEv"},{"b":"80938F000","o":"E926","s":"pthread_sigmask"},{"b":"80938F000","o":"DECF","s":"pthread_getspecific"}],"processInfo":{ "mongodbVersion" : "3.6.2", "gitVersion" : "489d177dbd0f0420a8ca04d39fd78d0a2c539420", "compiledModules" : [], "uname" : { "sysname" : "FreeBSD", "release" : "11.1-RELEASE-p1", "version" : "FreeBSD 11.1-RELEASE-p1 #0: Wed Aug  9 11:55:48 UTC 2017     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC", "machine" : "amd64" } }}
 mongod(_ZN5mongo15printStackTraceERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEE+0x36) [0x55e6516]
 mongod(_ZN5mongo15clearSignalMaskEv+0x3B5) [0x55e5ff5]
 mongod(_ZN5mongo29reportOutOfMemoryErrorAndExitEv+0x9A) [0x55e58aa]
 libthr.so.3(pthread_sigmask+0x536) [0x80939d926]
 libthr.so.3(pthread_getspecific+0xE5F) [0x80939cecf]
-----  END BACKTRACE  -----

Is it something I missed or made wrong?

Comment by Andrew Morrow (Inactive) [ 17/Oct/17 ]

weishan - Correct, you will not be able to opt out of secure allocation for the mongodb servers mongod and mongos with the disabledSecureAllocatorDomains facility unless you are running MongoDB 3.6 or newer. If we fix this bug, which is about the lack of support for that feature in the shell, for 3.6 GA, then the same would hold true for the shell. However, the shell is an interactive user program, so jailing it doesn't seem as important. You could certainly run the servers within a jail so that untrusted connections that managed to gain control over server execution were still contained in the jail, but run the shell to connect to the server for administrative tasks from outside the jail, where memory locking would be available. If we don't get this fixed for 3.6 GA (as is likely), we will fix it in the 3.7 development cycle, and then consider backporting it to 3.6.small.

Longer term though, it would seem desirable for FreeBSD to offer support for memory locking within jails.

Comment by Wei Shan Ang [ 16/Oct/17 ]

Hi Andrew,

For people running mongod in a less privileged environment like FreeBSD jails, it is not possible to mlock inside the jail itself.

As such, both mongod and mongo shell will not be able to disable this behaviour until MongoDB 3.6?

Comment by Andrew Morrow (Inactive) [ 16/Oct/17 ]

Hi weishan - No, the disabledSecureAllocatorDomains feature is new on the master branch and will ship with MongoDB 3.6. We do not currently plan to backport this work because it is not a bugfix, and because there are workarounds for older branches (either configuring the system limits to allow more secure memory, or granting the user running the shell/server the required capabilities).

Comment by Wei Shan Ang [ 16/Oct/17 ]

Is this setParameter available in 3.2.17 yet?
mongod --version
db version v3.2.17
git version: 186656d79574f7dfe0831a7e7821292ab380f667
OpenSSL version: OpenSSL 1.0.2j-freebsd 26 Sep 2016
allocator: system
modules: none
build environment:
distarch: x86_64
target_arch: x86_64

mongod --setParameter=disabledSecureAllocatorDomains=1 --config /usr/local/etc/mongodb.conf.ws
BadValue: Illegal --setParameter parameter: "disabledSecureAllocatorDomains"

Based on the output of db.runCommand(

{setParameter:1,help:true}

).help on 3.2.17, it is not yet available.

Thanks!

Generated at Thu Feb 08 04:27:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.