Using secure configurations and setup of Docker images

[ioah86]

Hello,

I recently ran the CoGuard CLI (https://github.com/coguardio/coguard-cli) on the wordpress Docker image. It found an Apache HTTPD configuration file, in addition to doing some scans on the last Dockerfile itself.

It found 20 issues, out of which 13 were high severity. Here are a couple of lines of the output:

          XXXXXXXXXXXK
      xXXXXXXXXXXXXXXXXXXl
    XXXXX.            ;XXXXO       .XXXXXXXXXX     oXXXX        XXXXc       xXXXX'       'XXXXXXXXXXXXO     XXXXXXXXXXX;
  lXXXx    lXXXXXXXX,    0XXX;   cXXXXXXXXXXXXXX.  oXXXX        XXXXc      :XXXXXX       'XXXXXXXXXXXXXXX.  XXXXXXXXXXXXXX'
 dXXX.  .XXXXXx  0XXXXX    ...  dXXXX'      cXXXX. oXXXX        XXXXc     .XXXXXXX0      'XXXX'      OXXXX  XXXXo     .XXXXk
;XXX   xXXX    do   .XXXc      'XXXX,              oXXXX        XXXXc     XXXX.oXXXd     'XXXX'      ,XXXX. XXXXd       XXXXd
0XXl  ;XXk     ,,     KXX.     lXXXX               oXXXX        XXXXc    OXXXl  0XXX:    'XXXX'     .XXXXk  XXXXd       lXXXX
XXX:  oXX: cll.  ,ll: oXX;     oXXXX    .XXXXXXXXo oXXXX        XXXXc   oXXXO   .XXXX.   'XXXXXXXXXXXXXX;   XXXXd       lXXXX
OXXo  ;XXO     do     KXX.     cXXXX.   .XXXXXXXXo oXXXX        XXXXc  ;XXXX     :XXXX   'XXXXXXXXXXXXl     XXXXd       xXXX0
;XXX.  oXXX    ,,   .XXX:      .XXXXo        XXXXo lXXXX       .XXXX: .XXXXXXXXXXXXXXXO  'XXXX'   .XXXXd    XXXXd      ,XXXX;
 oXXX.   XXXXXX:lXXXXXK   ;XXX: .XXXXX.      XXXXo  XXXXX     .XXXX0  XXXXx        XXXXo 'XXXX'    .XXXX0   XXXXd    .XXXXX,
  cXXXO    ;XXXXXXXX.    XXXX'    xXXXXXXXXXXXXXX.   kXXXXXXXXXXXXd  kXXXX         ,XXXX:'XXXX'      XXXXK  XXXXXXXXXXXXXl
    KXXXX;            lXXXXx         'XXXXXXX           cXXXXXX;    lXXXX,          dXXXXlXXXX'       KXXXX XXXXXXXXK
      oXXXXXXXXXXXXXXXXXX:
          OXXXXXXXXXXd
    
Docker version 20.10.17, build 100c70180f detected.
SCANNING IMAGE wordpress
Found file /etc/apache2/apache2.conf
Found configuration files for apache in non-standard location. Keep in mind that this is a heuristic method.
SCANNING OF wordpress COMPLETED
Scan result_jsons: 20 checks failed, 13 High/5 Medium/2 Low
 X Severity 5: apache_deny_root_directory
Documentation: Ensure that the root directory access is specifically denied. Otherwise, it is possible that an attacker can
               gain access to files through root directory mapping. Remediation: Create a <Directory> Require all denied
               </Directory> directive Source:https://httpd.apache.org/docs/2.4/mod/core.html#directory
 X Severity 5: apache_root_directory_options_none
Documentation: With the options directive, one can allow scripts to be executed, follow symlinks, do content negotiation, etc.
               In the root directory, the Options directive should always be set to None. Remediation: Create a <Directory>
               Options None </Directory> directive Source:https://httpd.apache.org/docs/2.4/mod/core.html#directory
 X Severity 5: apache_enable_ssl
Documentation: We should never have any communication done using unencrypted channels. This check tests if the mod_ssl.so
               module is loaded and that SSLProtocol is set, together with a proper SSL certificate file and a key file.
               Remediation: Load the `mod_ssl.so` modules, and set the `SSLCertificateFile` and `SSLCertificateKeyFile` keys to
               the paths of the respective certificate and key file.
 X Severity 5: apache_load_logging_module
Documentation: Logging is important to monitor the activity on the server and detect anomalies. Remediation: Load the module
               `mod_log_config` module in the configuration Source: https://httpd.apache.org/docs/2.4/mod/mod_log_config.html
 X Severity 5: apache_load_security_module
Documentation: ModSecurity is a module that acts as a web application firewall for monitoring, logging, and access control. It
               should always be loaded and configured Remediation steps: Load the module by adding `LoadModule security2_module
               modules/mod_security2.so` Source: https://www.modsecurity.org/download.html
 X Severity 4: dockerfile_last_user_should_be_non_root
Documentation: When creating a docker container, it is possible to set the user who is actually running the application and any
               command on the container. It is important to specifically use the `USER` directive in any Dockerfile to ensure
               that the user is not root and has unnecessary privileges.  Remediation: Have at least one `USER` directive in
               your Dockerfile, and the last user directive should not reference the root user or root group.  Source:
               https://docs.docker.com/engine/reference/builder/#user


...

I don't think it would be hard to address these issues, and harden the produced Docker images. Furthermore, there is a github action which can be used to ensure that configurations stay hardened in future images: https://github.com/marketplace/actions/coguard-docker-image-scan

I would love to open the discussion on fixing some of those configuration issues, and also add the continuous check into the workflow.
It is free and would help maintain a high degree of quality.

Thoughts?

[tianon]

Most of our Apache configuration comes from Debian's own defaults (or direct recommendations from WordPress, where available). 😬

A few notes:

• apache_enable_ssl - definitely not trivial to enable out-of-the-box (which certificate do we use? generate a new self-signed? IMO that would make things even worse because it would train users to ignore the security warning entirely 😬)

• dockerfile_last_user_should_be_non_root - this image is following a similar pattern to many other official images where we default to running as root such that we can correct permissions before we step-down, but support users invoking directly as non-root if they prefer to handle permissions themselves in favor of a slightly more secure setup

[ioah86]

Yes, some scan results may be not applicable here, but others are. The last user not being root is something which is considered best practice in general, and, as you may foresee, if someone uses a template (which these public images are), they assume it is done in the best way possible. Most of the time, people are not even aware that they are running their final commands as root, and to enforce an intermediate user on the higher level is beneficial to making the world of Docker images and containers more secure.

[ioah86]

And, keep in mind that these are just a snapshot. You can run CoGuard-CLI on any of those images and see the output and what it may find. I am happy to discuss further and assist in finding ways to fix it. We also have a GitHub action which can be included into the general build process: https://github.com/marketplace/actions/coguard-docker-image-scan