Change Details

The current Blubber Dockerfile output contains `COPY` instructions that don't specify any non-root owner (i.e. a `--chown uid:gid` flag with the configured `runs.uid` and `runs.gid`). This was not the intended behavior of Blubber, however, it may actually be a more sensible default for security reasons if the runtime user cannot change application files. Perhaps we should move to a scheme where all project and shared lib files are locked down as root owned (i.e. `RUN chown -R root:root /opt/lib [runs.in]`) at the end of the Dockerfile, but support configuration that will chown selective files/dirs to the `runs.as` user?

Blubber currently outputs a buildable `Dockerfile` in five distinct phases:`PhasePrivileged`, `PhasePrivilegeDropped`, `PhasePreInstall`, `PhaseInstall`, and `PhasePostInstall`. Instructions that could possibly allow arbitrary code to be executed are only output after the `PhasePrivilegeDropped` phase is reached and the runtime user is set to whatever is configured for `runs.as`, and this serves as a very basic security model to disallow users of Blubber to control what will eventually be run as root at container runtime. However, the `COPY` instructions as they're currently output result in files owned as `root`, not the `runs.as` user, so the currently implementation is borked. Add to that, if the current implementation were fixed, the runtime user would then have read/write access to the application's files and installs dependencies. This is also not desirable. After discussing it, this is the basic model we want using distinct levels of privilege (not just `root` and the `runs.as` user): 1. (as `root`) Only APT package installation and other operations that can't lead to arbitrary execution are done. 2. (as `somebody`) Install dependencies and copy over application files. 3. (as `somebody`) Allow configuration for some application files/dirs to be `chown`'d as the `runs.as` user (temp build directories, etc.). 4. (as `[runs.as]`) Execute entrypoint.

The current Blubber Dockerfile output contains `COPY` instructions that don't specify any non-root owner (i.e.Blubber currently outputs a buildable `Dockerfile` in five distinct phases:`PhasePrivileged`, `PhasePrivilegeDropped`, `PhasePreInstall`, `PhaseInstall`, and `PhasePostInstall`. Instructions that could possibly allow arbitrary code to be executed are only output after the `PhasePrivilegeDropped` phase is reached and the runtime user is set to whatever is configured for `runs.as`, a `--chown uid:gid` flag with the configured `runs.uid` and `runs.gid`).nd this serves as a very basic security model to disallow users of Blubber to control what will eventually be run as root at container runtime. However, This was not the intended behavior of Blubberthe `COPY` instructions as they're currently output result in files owned as `root`, howevernot the `runs.as` user, it may actually be a more sensible default for security reasons if the runtime user cannot change application filesso the currently implementation is borked. Perhaps we should move to a scheme where all project and shared lib files are locked down as root owned (i.e.Add to that, if the current implementation were fixed, the runtime user would then have read/write access to the application's files and installs dependencies. This is also not desirable. After discussing it, this is the basic model we want using distinct levels of privilege (not just `root` and the `runs.as` user): 1. (as `root`) Only APT package installation and other operations that can't lead to arbitrary execution are done. 2. (as `somebody`) Install dependencies and copy over application files. 3. (as `somebody`) Allow configuration for some application files/dirs to be `chown`'d as the `runs.as` user (temp build directories, `RUN chown -R root:root /opt/lib [runs.in]`) at the end of the Dockerfile,etc.). 4. but support configuration that will chown selective files/dirs to the `runs.as` user?(as `[runs.as]`) Execute entrypoint.