security reorg

bin/builddata/htaccess.yaml

@@ -993,7 +993,7 @@ outputs:
   - 'v2.2'
 ---
 redirect-path: '/tutorial/create-a-vulnerability-report'
-url-base: '/administration/vulnerability-report'
+url-base: '/administration/vulnerability-notification'
 type: 'redirect'
 code: 303
 outputs:
@@ -1429,7 +1429,7 @@ outputs:
   - 'manual'
   - 'after-v2.2'
 ---
-redirect-path: '/administration/vulnerability-report'
+redirect-path: '/administration/vulnerability-notification'
 url-base: '/tutorial/create-a-vulnerability-report'
 type: 'redirect'
 code: 301
@@ -1766,8 +1766,64 @@ code: 303
 outputs:
   - 'v2.2'
 ---
-redirect-path: '/release-notes/password-hashing-insecurity'
-url-base: '/core/security'
+redirect-path: '/release-notes/security'
+url-base: '/tutorial/control-access-to-mongodb-with-authentication/#password-hashing-insecurity'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/core/security-introduction'
+url-base: '/administration/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/core/security-risk-management-strategies'
+url-base: '/administration/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/core/limit-network-risk-exposure'
+url-base: '/administration/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/core/limit-interface-related-risks'
+url-base: '/administration/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/administration/security-network'
+url-base: '/administration/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/administration/security-access-control'
+url-base: '/tutorial/control-access-to-mongodb-with-authentication'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/reference/security'
+url-base: '/security'
+type: 'redirect'
+code: 303
+outputs:
+  - 'v2.2'
+---
+redirect-path: '/reference/default-mongodb-port'
+url-base: '/administration/security'
 type: 'redirect'
 code: 303
 outputs:

source/administration/security-access-control.txt

@@ -0,0 +1,12 @@
+========================
+Access Control Tutorials
+========================
+
+.. default-domain:: mongodb
+
+The following tutorials provide instructions on how to enable
+authentication and limit access for users with privilege roles.
+
+.. include:: /includes/dfn-list-security-tutorials-access-control.rst
+
+.. include:: /includes/toc-security-tutorials-access-control.rst

source/administration/security-network.txt

@@ -0,0 +1,12 @@
+==========================
+Network Security Tutorials
+==========================
+
+.. default-domain:: mongodb
+
+The following tutorials provide information on handling network
+security for MongoDB.
+
+.. include:: /includes/dfn-list-security-tutorials-network.rst
+
+.. include:: /includes/toc-security-tutorials-network.rst

source/administration/security.txt

@@ -0,0 +1,12 @@
+==================
+Security Tutorials
+==================
+
+.. default-domain:: mongodb
+
+The following tutorials provide instructions for enabling and using
+the security features available in MongoDB.
+
+.. include:: /includes/dfn-list-spec-security-tutorials-landing.rst
+
+.. include:: /includes/toc-security-tutorials-landing.rst

source/core/access-control.txt

@@ -4,81 +4,79 @@ Access Control
 
 .. default-domain:: mongodb
 
-MongoDB provides support for authentication and authorization by storing
-a user's credentials and privileges in a database's :data:`system.users
-<<database>.system.users>` collection. MongoDB provisions authentication
-and access on a per-database level. Users exist in the context of a
-single logical database.
-
-For MongoDB Enterprise installations, MongoDB also provides support for
-authentication using a Kerberos service. See
-:doc:`/tutorial/control-access-to-mongodb-with-kerberos-authentication`.
+MongoDB provides support for authentication and authorization on a
+per-database level. Users exist in the context of a single logical
+database.
+
+.. _authentication:
 
 Authentication
 --------------
 
-MongoDB provides support for basic authentication by:
-
-- storing user credentials in a database's :data:`system.users
-  <<database>.system.users>` collection, and
-
-- providing the :setting:`auth` and :setting:`keyFile` configuration
-  settings to enable authentication for a given :program:`mongod` or
-  :program:`mongos` instance.
+MongoDB provisions authentication, or verification of the user
+identity, on a per-database level. Authentication disables anonymous
+access to the database. For basic authentication, MongoDB stores the
+user credentials in a database's :data:`system.users
+<<database>.system.users>` collection.
 
-Authentication is **disabled** by default.
+Authentication is **disabled** by default. To enable authentication for
+a given :program:`mongod` or :program:`mongos` instance, use the
+:setting:`auth` and :setting:`keyFile` configuration settings. For
+details, see :doc:`/tutorial/enable-authentication`.
 
-.. versionadded 2.0: Before 2.0 sharded clusters *had* to run with
+.. versionadded 2.0: Before 2.0, sharded clusters *had* to run with
    trusted applications and a trusted networking configuration.
 
-To enable authentication, see the following:
+For MongoDB Enterprise installations, authentication using a Kerberos
+service is available. See
+:doc:`/tutorial/control-access-to-mongodb-with-kerberos-authentication`.
 
-- :doc:`/tutorial/enable-authentication`
+.. important::
+   You can authenticate as only one user for a given database. If you
+   authenticate to a database as one user and later authenticate on the
+   same database as a different user, the second authentication
+   invalidates the first. You can, however, log into a *different*
+   database as a different user and not invalidate your authentication
+   on other databases.
 
-- :doc:`/tutorial/control-access-to-mongodb-with-kerberos-authentication`
+.. _authorization:
 
 Authorization
 -------------
 
-MongoDB supports role-based access to databases and database operations
-by storing each user's roles in a :doc:`privilege document
-</reference/user-privileges>` in the :data:`system.users
-<<database>.system.users>` collection. For a description of privilege
-documents and of available roles, see :doc:`/reference/user-privileges`.
-
-.. versionchanged:: 2.4 The schema of :data:`system.users
-   <<database>.system.users>` changed to accommodate a more
-   sophisticated user privilege model, as defined in :doc:`privilege
-   documents </reference/user-privileges>`.
-
-The :data:`system.users <<database>.system.users>` collection is
-protected to prevent privilege escalation attacks. To access the
-collection, you must have the :authrole:`userAdmin` or
-:authrole:`userAdminAnyDatabase` role.
-
-To assign user roles, you must first create an admin user in the
-database. Then you create additional users, assigning them appropriate
-user roles.
-
-To assign user roles, see the following:
-
-- :doc:`/tutorial/add-user-administrator`
-
-- :doc:`/tutorial/add-user-to-database`
-
-User Roles in the admin Database
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The ``admin`` database provides roles not available in other databases,
-including a role that effectively makes a user a MongoDB system
-superuser. See :ref:`database-admin-roles` and :ref:`admin-roles`.
-
-Authentication to One Database at a Time
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can log in as only one user for a given database, including
-the ``admin`` database. If you authenticate to a database as one user
-and later authenticate on the same database as a different user, the
-second authentication invalidates the first. Logging into a *different*
-database, however, does not invalidate authentication on other
-databases.
+MongoDB provisions authorization, or access to databases and
+operations, on a per-database level. MongoDB uses a role-based approach
+to authorization, storing each user's roles in a :doc:`privilege
+document </reference/user-privileges>` in a database's
+:data:`system.users <<database>.system.users>` collection. For more
+information on privilege documents and available user roles, see
+:doc:`/reference/privilege-documents` and
+:doc:`/reference/user-privileges`.
+
+.. important:: The ``admin`` database provides roles that are
+   *unavailable* in other databases, including a role that effectively
+   makes a user a MongoDB system superuser. See
+   :ref:`database-admin-roles` and :ref:`admin-roles`.
+
+To assign roles to users, you must be a user with administrative role
+in the database. As such, you must first create an administrative user.
+For details, see :doc:`/tutorial/add-user-administrator` and
+:doc:`/tutorial/add-user-to-database`.
+
+``system.users`` Collection
+--------------------------------------
+
+A database's :data:`system.users <<database>.system.users>` collection
+stores information for authentication and authorization to that
+database. Specifically, the collection stores user credentials for
+authentication and user privilege information for authorization.
+MongoDB requires authorization to access the :data:`system.users
+<<database>.system.users>` collection in order to prevent privilege
+escalation attacks. To access the collection, you must have either
+:authrole:`userAdmin` or :authrole:`userAdminAnyDatabase` role.
+
+.. versionchanged:: 2.4 
+   The schema of :data:`system.users <<database>.system.users>` changed
+   to accommodate a more sophisticated authorization using user
+   privilege model, as defined in :doc:`privilege documents
+   </reference/user-privileges>`.

source/core/inter-process-authentication.txt

@@ -27,18 +27,22 @@ replica set members can reach your :program:`mongod` instances. If
 needed, use virtual private networks (VPNs) to ensure secure
 connections over wide area networks (WANs.)
 
-Additionally, MongoDB provides an authentication mechanism for
-:program:`mongod` and :program:`mongos` instances connecting to
-replica sets. These instances enable authentication but specify a
-shared key file that serves as a shared password.
+Enable Authentication in Replica Sets and Sharded Clusters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. versionadded:: 1.8
    Added support authentication in replica set deployments.
 
 .. versionchanged:: 1.9.1
    Added support authentication in sharded replica set deployments.
 
-To enable authentication add the following option to your configuration file:
+MongoDB provides an authentication mechanism for :program:`mongod` and
+:program:`mongos` instances connecting to replica sets. These instances
+enable authentication but specify a shared key file that serves as a
+shared password.
+
+To enable authentication, add the following option to your configuration
+file:
 
 .. code-block:: cfg
 

source/core/limit-interface-related-risks.txt

@@ -0,0 +1,79 @@
+=============================
+Limit Interface-Related Risks
+=============================
+
+.. default-domain:: mongodb
+
+The following section contains strategies to limit risks related to
+MongoDB interfaces.
+
+JavaScript and the Security of the ``mongo`` Shell
+--------------------------------------------------
+
+The following JavaScript evaluation behaviors of the :program:`mongo`
+shell represents risk exposures.
+
+JavaScript Expression or JavaScript File
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The :program:`mongo` program can evaluate JavaScript expressions using
+the command line :option:`--eval <mongo --eval>` option. Also, the
+:program:`mongo` program can evaluate a JavaScript file (``.js``)
+passed directly to it (e.g. ``mongo someFile.js``). 
+
+Because the :program:`mongo` program evaluates the JavaScript without
+validating the input, this behavior presents a vulnerability.
+
+``.mongorc.js`` File
+~~~~~~~~~~~~~~~~~~~~
+
+If a ``.mongorc.js`` file exists [#mongorc-location]_, the :program:`mongo` shell will
+evaluate a ``.mongorc.js`` file before starting. You can disable this
+behavior by passing the :option:`mongo --norc` option.
+
+.. [#mongorc-location] On Linux and Unix systems, :program:`mongo`
+   reads the :file:`.mongorc.js` file from :file:`{$HOME}/.mongorc.js`
+   (i.e. :file:`~/.mongorc.js`). On Windows, :program:`mongo.exe` reads
+   the :file:`.mongorc.js` file from :file:`{%HOME%}\.mongorc.js` or
+   :file:`{%HOMEDRIVE%}\{%HOMEPATH%}\.mongorc.js`.
+
+HTTP Status Interface
+---------------------
+
+The HTTP status interface provides a web-based interface that includes
+a variety of operational data, logs, and status reports regarding the
+:program:`mongod` or :program:`mongos` instance. The HTTP interface is
+always available on the port numbered ``1000`` greater than the primary
+:program:`mongod` port. By default, the HTTP interface port is
+``28017``, but is indirectly set using the :setting:`port` option which
+allows you to configure the primary :program:`mongod` port.
+
+Without the :setting:`rest` setting, this interface is entirely
+read-only, and limited in scope; nevertheless, this interface may
+represent an exposure. To disable the HTTP interface, set the
+:setting:`nohttpinterface` run time option or the
+:option:`--nohttpinterface <mongod --nohttpinterface>` command line
+option. See also :ref:`security-port-numbers`.
+
+.. _rest-api:
+
+REST API
+--------
+
+The REST API to MongoDB provides additional information and write
+access on top of the HTTP Status interface. While the REST API does not
+provide any support for insert, update, or remove operations, it does
+provide administrative access, and its accessibility represents a
+vulnerability in a secure environment. The REST interface is *disabled*
+by default, and is not recommended for production use.
+
+If you must use the REST API, please control and limit access to the
+REST API. The REST API does not include any support for
+authentication, even when running with :setting:`auth`
+enabled.
+
+See the following documents for instructions on restricting access to
+the REST API interface:
+
+- :doc:`/tutorial/configure-linux-iptables-firewall`
+- :doc:`/tutorial/configure-windows-netsh-firewall`