docker:S6504 not working correctly

Hello community!

We are facing a strange issue with docker:S6504 rule.
We fixed our Dockerfile based on Sonarqubes recommendation, but it still complains …
See screenshot.
Basically it is about this line: COPY --chown=node:node --chmod=644 src .

Reference: Docker static code analysis: Having executables not owned by root is security-sensitive

Any idea?

Thanks,
Klaus

SonarQube Version 10.3 (build 82913), zip

Hello @NikolausBrunner,

Thanks for reporting your issue with our rule!

As part of an effort to improve this rule, we raise an issue every time we encounter a chown-flag where the user is not root, independent of its writeability. The rationale is that the file permissions could be changed if the user is controlled.

In the compliant example of the SonarQube documentation, we use --chown=root:root, which should not raise an issue.
The following COPY-Instructions should not raise an issue in your analysis:

  • COPY --chown=root:node --chmod=644 src .
  • COPY --chown=root:root --chmod=644 src .

As the rule description can lead to confusion about this rule, we will try to word it more clearly.

Best,
Jonas

1 Like

Thanks Jonas for your kind feedback.
Hm, but what if the src folder contains sub-folders - then the execute permission is required for the non-root user to enter the folder, or?

Klaus

Hi Nikolaus!

Thank you for your feedback, questions and for your patience, I sincerely apologize for the time it has taken me to respond to you. I am part of the application security team responsible for the logic and text of these rules.

In general, the goal of the rule is to help users enforce the principle of least privilege: Entities should have as least privileges as possible so that an intruder who gains access to the file system is prevented from compromising more things. In that case, the “least privilege” principle is applied to the file system, and for example, it can also be applied to user management systems (LDAP, IAM, etc.).

what if the src folder contains sub-folders - then the execute permission is required for the non-root user to enter the folder, or?


Edit
You can actually run

COPY --chown=root:node --chmod=640 src .
RUN chmod -R g+X src

It should actually give the possibility to access directories without adding the ‘x’ bit to their underlying files. I did not test but you might need to temporarily switch to the root user to do so, since node’s USER is always set to node unless overridden. It is unfortunately not possible to do it with the COPY command yet, as it still only accepts octal notation. String notation is tracked in moby/buildkit#1951

TLDR: You might need to do

COPY --chown=root:node --chmod=640 src .
USER root
RUN chmod -R g+X src
USER node

Previous response, edited

Yes, users must have execute permission to a directory in order to enter it. In your use case, this means that “node” should have at least rx permissions. Here this would mean adding “650” permissions in favor of node. It would prevent any intruder with “node” permissions from writing to these files while allowing you to use them. If your code gets attacked and accessed via the “node” user, this is securing it. If you have some code running as root, this is not. But in any case, using root to run production code is never ok.


However, if you realize that your code randomly raises ENOENT or equivalent errors, it means node or your code tried to write to some file in it. In that case, theoretically following docker:S6504 would mean setting 670, but it’s unnecessarily complex. In that case, I see two choices:

Either

  • Identify the folders where the code wants to write and create specific “COPY -chmod=700” commands for them (and less permissions to the other folders)
  • Or set “-chmod=700” to src because node is susceptible to write anywhere in src

I would be interested to have your input if the resulting Dockerfile starts to become ugly because even if secure, it could now become a code smell since its maintainability would be more complex.
As a security practitioner, I know that in general, when something security-related is annoying to do, users do not do it or actively bypass it. So we want to avoid “ugly solutions” as much as possible :smiley:
(If you do, please ping me by typing @Loris_Sierra)

Cheers!

Loris

1 Like