Merge "Update permission checks to include top level directory checks"

security-guide/source/block-storage/checklist.rst

@@ -13,7 +13,8 @@ intentionally or accidentally, modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues resulting in a
 denial of service to the other end users. Thus user ownership of such critical
 configuration files must be set to root and group ownership must be set to
-cinder.
+cinder. Additionally, the containing directory should have the same ownership
+to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -23,6 +24,7 @@ Run the following commands:
     $ stat -L -c "%U %G" /etc/cinder/api-paste.ini | egrep "root cinder"
     $ stat -L -c "%U %G" /etc/cinder/policy.json | egrep "root cinder"
     $ stat -L -c "%U %G" /etc/cinder/rootwrap.conf | egrep "root cinder"
+    $ stat -L -c "%U %G" /etc/cinder | egrep "root cinder"
 
 **Pass:** If user and group ownership of all these config files is set
 to root and cinder respectively. The above commands show output of root cinder.
@@ -47,9 +49,15 @@ Run the following commands:
     $ stat -L -c "%a" /etc/cinder/api-paste.ini
     $ stat -L -c "%a" /etc/cinder/policy.json
     $ stat -L -c "%a" /etc/cinder/rootwrap.conf
+    $ stat -L -c "%a" /etc/cinder
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of 640
-translates into owner r/w, group r, and no rights to others i.e. "u=rw,g=r,o=".
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640/750 translates into owner r/w,
+group r, and no rights to others i.e. "u=rw,g=r,o=".
 Note that with :ref:`check_block_01` and permissions set to 640, root has
 read/write access and cinder has read access to these configuration files. The
 access rights can also be validated using the following command. This command

security-guide/source/compute/checklist.rst

@@ -13,7 +13,8 @@ intentionally or accidentally, modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues causing a
 denial of service to the other end users. User ownership of such critical
 configuration files must be set to ``root`` and group ownership must be set to
-``nova``.
+``nova``. Additionally, the containing directory should have the same ownership
+to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -23,6 +24,7 @@ Run the following commands:
     $ stat -L -c "%U %G" /etc/nova/api-paste.ini | egrep "root nova"
     $ stat -L -c "%U %G" /etc/nova/policy.json | egrep "root nova"
     $ stat -L -c "%U %G" /etc/nova/rootwrap.conf | egrep "root nova"
+    $ stat -L -c "%U %G" /etc/nova | egrep "root nova"
 
 **Pass:** If user and group ownership of all these config files is set
 to ``root`` and ``nova`` respectively. The above commands show output of
@@ -51,9 +53,13 @@ Run the following commands:
     $ stat -L -c "%a" /etc/nova/policy.json
     $ stat -L -c "%a" /etc/nova/rootwrap.conf
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of 640
-translates into owner r/w, group r, and no rights to others. For example,
-"u=rw,g=r,o=".
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640/750 translates into owner r/w,
+group r, and no rights to others. For example, "u=rw,g=r,o=".
 
 .. note::
 
@@ -72,7 +78,7 @@ translates into owner r/w, group r, and no rights to others. For example,
     mask         r--
     other        ---
 
-**Fail:** If permissions are not set to at least 640.
+**Fail:** If permissions are not set to at least 640/750.
 
 Recommended in: :doc:`../compute`.
 

security-guide/source/identity/checklist.rst

@@ -11,7 +11,8 @@ intentionally or accidentally modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues causing a
 denial of service to the other end users. Thus user and group ownership
 of such critical configuration files must be set to that component
-owner.
+owner. Additionally, the containing directory should have the same ownership
+to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -24,6 +25,7 @@ Run the following commands:
     $ stat -L -c "%U %G" /etc/keystone/ssl/certs/signing_cert.pem | egrep "keystone keystone"
     $ stat -L -c "%U %G" /etc/keystone/ssl/private/signing_key.pem | egrep "keystone keystone"
     $ stat -L -c "%U %G" /etc/keystone/ssl/certs/ca.pem | egrep "keystone keystone"
+    $ stat -L -c "%U %G" /etc/keystone | egrep "keystone keystone"
 
 **Pass:** If user and group ownership of all these config files is set
 to keystone. The above commands show output of keystone keystone.
@@ -50,10 +52,16 @@ Run the following commands:
     $ stat -L -c "%a" /etc/keystone/ssl/certs/signing_cert.pem
     $ stat -L -c "%a" /etc/keystone/ssl/private/signing_key.pem
     $ stat -L -c "%a" /etc/keystone/ssl/certs/ca.pem
+    $ stat -L -c "%a" /etc/keystone
 
-**Pass:** If permissions are set to 640 or stricter.
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
 
-**Fail:** If permissions are not set to at least 640.
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750.
+
+**Fail:** If permissions are not set to at least 640/750.
 
 Recommended in: :ref:`internally-implemented-authentication-methods`.
 

security-guide/source/image-storage/checklist.rst

@@ -13,7 +13,8 @@ intentionally or accidentally, modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues resulting in a
 denial of service to the other end users. Therefore, user ownership of such
 critical configuration files must be set to ``root`` and group ownership
-must be set to ``glance``.
+must be set to ``glance``. Additionally, the containing directory should have
+the same ownership to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -30,6 +31,7 @@ Run the following commands:
    $ stat -L -c "%U %G" /etc/glance/policy.json | egrep "root glance"
    $ stat -L -c "%U %G" /etc/glance/schema-image.json | egrep "root glance"
    $ stat -L -c "%U %G" /etc/glance/schema.json | egrep "root glance"
+   $ stat -L -c "%U %G" /etc/glance | egrep "root glance"
 
 **Pass:** If user and group ownership of all these configuration files is set
 to root and glance respectively. The above commands show output of root glance.
@@ -59,10 +61,15 @@ Run the following commands:
     $ stat -L -c "%a" /etc/glance/policy.json
     $ stat -L -c "%a" /etc/glance/schema-image.json
     $ stat -L -c "%a" /etc/glance/schema.json
+    $ stat -L -c "%a" /etc/glance
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of 640
-translates into owner r/w, group r, and no rights to others. For example,
-``u=rw,g=r,o=``.
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640/750 translates into owner r/w,
+group r, and no rights to others. For example, ``u=rw,g=r,o=``.
 
 .. note::
 

security-guide/source/networking/checklist.rst

@@ -13,7 +13,8 @@ intentionally or accidentally modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues causing a
 denial of service to the other end users. Thus user ownership of such critical
 configuration files must be set to root and group ownership must be set to
-neutron.
+neutron. Additionally, the containing directory should have the same ownership
+to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -23,6 +24,7 @@ Run the following commands:
     $ stat -L -c "%U %G" /etc/neutron/api-paste.ini | egrep "root neutron"
     $ stat -L -c "%U %G" /etc/neutron/policy.json | egrep "root neutron"
     $ stat -L -c "%U %G" /etc/neutron/rootwrap.conf | egrep "root neutron"
+    $ stat -L -c "%U %G" /etc/neutron | egrep "root neutron"
 
 **Pass:** If user and group ownership of all these config files is set
 to root and neutron respectively. The above commands show output of root
@@ -48,9 +50,16 @@ Run the following commands:
     $ stat -L -c "%a" /etc/neutron/api-paste.ini
     $ stat -L -c "%a" /etc/neutron/policy.json
     $ stat -L -c "%a" /etc/neutron/rootwrap.conf
+    $ stat -L -c "%a" /etc/neutron
+
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640 translates into owner r/w,
+group r, and no rights to others i.e. "u=rw,g=r,o=".
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of 640
-translates into owner r/w, group r, and no rights to others i.e. "u=rw,g=r,o=".
 Note that with :ref:`check_neutron_01` and permissions set to 640, root has
 read/write access and neutron has read access to these configuration files. The
 access rights can also be validated using the following command. This command

security-guide/source/secrets-management/checklist.rst

@@ -15,7 +15,8 @@ intentionally or accidentally, modifies or deletes any of the parameters
 or the file itself then it would cause severe availability issues
 resulting in a denial of service to the other end users. User ownership
 of such critical configuration files must be set to root and group
-ownership must be set to barbican.
+ownership must be set to barbican. Additionally, the containing directory
+should have the same ownership to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -24,6 +25,7 @@ Run the following commands:
   $ stat -L -c "%U %G" /etc/barbican/barbican.conf | egrep "root barbican"
   $ stat -L -c "%U %G" /etc/barbican/barbican-api-paste.ini | egrep "root barbican"
   $ stat -L -c "%U %G" /etc/barbican/policy.json | egrep "root barbican"
+  $ stat -L -c "%U %G" /etc/barbican | egrep "root barbican"
 
 **Pass:** If user and group ownership of all these config files is set
 to root and barbican respectively. The above commands show output of
@@ -48,10 +50,15 @@ Run the following commands:
   $ stat -L -c "%a" /etc/barbican/barbican.conf
   $ stat -L -c "%a" /etc/barbican/barbican-api-paste.ini
   $ stat -L -c "%a" /etc/barbican/policy.json
+  $ stat -L -c "%a" /etc/barbican
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of
-640 translates into owner r/w, group r, and no rights to others, for
-example "u=rw,g=r,o=".
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640 translates into owner r/w,
+group r, and no rights to others, for example "u=rw,g=r,o=".
 
 .. note::
   With :ref:`check_key_mgr_01` and permissions set to 640, root

security-guide/source/shared-file-systems/checklist.rst

@@ -15,7 +15,8 @@ intentionally or accidentally, modifies or deletes any of the parameters or
 the file itself then it would cause severe availability issues resulting in a
 denial of service to the other end users. Thus user ownership of such critical
 configuration files must be set to root and group ownership must be set to
-manila.
+manila. Additionally, the containing directory should have the same ownership
+to ensure that new files are owned correctly.
 
 Run the following commands:
 
@@ -25,6 +26,7 @@ Run the following commands:
     $ stat -L -c "%U %G" /etc/manila/api-paste.ini | egrep "root manila"
     $ stat -L -c "%U %G" /etc/manila/policy.json | egrep "root manila"
     $ stat -L -c "%U %G" /etc/manila/rootwrap.conf | egrep "root manila"
+    $ stat -L -c "%U %G" /etc/manila | egrep "root manila"
 
 **Pass:** If user and group ownership of all these config files is set
 to root and manila respectively. The above commands show output of root manila.
@@ -49,9 +51,15 @@ Run the following commands:
     $ stat -L -c "%a" /etc/manila/api-paste.ini
     $ stat -L -c "%a" /etc/manila/policy.json
     $ stat -L -c "%a" /etc/manila/rootwrap.conf
+    $ stat -L -c "%a" /etc/manila
 
-**Pass:** If permissions are set to 640 or stricter. The permissions of 640
-translates into owner r/w, group r, and no rights to others i.e. "u=rw,g=r,o=".
+A broader restriction is also possible: if the containing directory is set
+to 750, the guarantee is made that newly created files inside this directory
+would have the desired permissions.
+
+**Pass:** If permissions are set to 640 or stricter, or the containing
+directory is set to 750. The permissions of 640 translates into owner r/w,
+group r, and no rights to others i.e. "u=rw,g=r,o=".
 Note that with :ref:`check_shared_fs_01` and permissions set to 640, root has
 read/write access and manila has read access to these configuration files. The
 access rights can also be validated using the following command. This command