Note that Docker-Containers from before February 2023 are not vulnerable to the credential disclosure.

I haven’t seen this posted yet here, but anybody self-hosting OwnCloud in a containerized environment may be exposing sensitive environment variables to the public internet. There may be other implications as well.

    • sudneo@lemmy.worldEnglish
      4·
      1 年前

      In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).

    • sphericth0r@kbin.social
      2·
      1 年前

      It’s probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there’s no way to secure an insecure implementation of secrets access

      • sudneo@lemmy.worldEnglish
        2·
        1 年前

        They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.

        Of course you can mess up a secret implementation, but a chmod’d 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.

        Security-wise, ENV variables are worse compared to just a mounted config file, for example.