Giter VIP home page Giter VIP logo

Comments (8)

thaJeztah avatar thaJeztah commented on June 14, 2024

This eliminates the need to assign privileges to the container to be able to execute a privileged command. This behavior will allow administrators to expand the functionality of the container without endangering it.

Can you provide more context about what the "privileged" operation would do? Is this to run the command with --privileged ?

docker build does not allow for --privileged to be used, which is by design; containers executed during build (such as to execute RUN) are intended to provide a reproducible sandboxed environment. Container started with --privileged disable all security boundaries for the container (a container with --privileged does not "contain"), which means that such a container can compromise the host, as well as modify state of the host (making the environment no longer reproducible). See the (long) discussion on this ticket;

The builder is now maintained in the BuildKit project (), and since that ticket, an alternative proposal was created;

Which added --security flag to the RUN command, which is available in the experimental ("labs") Dockerfile syntax; https://docs.docker.com/reference/dockerfile/#run---security.

However, as the feature (as mentioned earier) is insecure. it requires the BuildKit configuration to be exlicitly configured to allow the feature, as well as entitlements to be passed when triggering the build; #1916 (comment)

from moby.

alexeyp0708 avatar alexeyp0708 commented on June 14, 2024

@thaJeztah
Perhaps I proposed the idea a little unharmoniously.
It would be right to implement such an idea ENTRYPOINT --security=insecure or ENTRYPOINT --privileged
This idea came to me at the stage of considering issues #8177 or #3465
My target was to unmount the default volume. And the only way to disable it is to disable it in the container viaumount /volume . But this requires privileged permissions run --privileged or run --cap-add=SYS_ADMIN.
Yes, I know there is RUN --security=insecure in Dockerfile. But these instructions apply at the time of build . For example, at this moment your volumes are not mounted (buildkit) and the container networks is not connected. Volumes declared as metadata and are mounted only when the container is runned. #33842 (comment)

The purpose of this solution is to ensure that a number of privileged commands are executed in ENTRYPOINT (or before executing ENTRYPOINT ) when the container is runned. At the same time, the entire assembly has been completedand volumes are mounted and networks connected. Also at the same time, we do not assign privileges to the container, thereby maintaining its security.
RUN --security=insecure will not be able to provide this, since the volumes are not yet mounted and networks are not connected when the command is executed

from moby.

alexeyp0708 avatar alexeyp0708 commented on June 14, 2024

As I understand it, it’s better to move this topic to moby/buildkit

from moby.

tonistiigi avatar tonistiigi commented on June 14, 2024

It is intentional that such flags from docker run can not be embedded into the image config. Docker security model implies that if user runs untrusted image, the application is restricted into container security sandbox. All insecure flags like --privileged --security-opt, --cap-add, bind mounts etc. that allow breakout from sandbox need to be set by the user from the command line.

There are some previous attempts #32801 to let the image define the exact options that it needs, and the user confirms it by allowing access to privileged features, but nothing like this is currently in the works afaik.

from moby.

alexeyp0708 avatar alexeyp0708 commented on June 14, 2024

It is intentional that such flags from docker run can not be embedded into the image config. Docker security model implies that if user runs untrusted image, the application is restricted into container security sandbox. All insecure flags like --privileged --security-opt, --cap-add, bind mounts etc. that allow breakout from sandbox need to be set by the user from the command line.

There are some previous attempts #32801 to let the image define the exact options that it needs, and the user confirms it by allowing access to privileged features, but nothing like this is currently in the works afaik.

https://docs.docker.com/reference/dockerfile/#run---security

The official documentation now says differently.

Additional options are currently being added as experimental features to moby/buildkit

from moby.

tonistiigi avatar tonistiigi commented on June 14, 2024

Yes, I know there is RUN --security=insecure in Dockerfile. But these instructions apply at the time of build .

The purpose of this solution is to ensure that a number of privileged commands are executed in ENTRYPOINT (or before executing ENTRYPOINT ) when the container is runned.

As you said yourself RUN --security is for controlling sandbox of the build commands (and still requires allowing such behavior from CLI flags), but you were asking for saving privileged options into image metadata that would run when container is invoked.

from moby.

alexeyp0708 avatar alexeyp0708 commented on June 14, 2024

As you said yourself RUN --security is for controlling sandbox of the build commands (and still requires allowing such behavior from CLI flags), but you were asking for saving privileged options into image metadata that would run when container is invoked.

The idea was that the user would have the opportunity to declare privileged commands in the Dockerfile before running ENTRYPOINT. In this case, there would be no need to assign privileges to the container (docker run --privileged)

From your findings -this means the idea is not feasible. (((

from moby.

alexeyp0708 avatar alexeyp0708 commented on June 14, 2024

@tonistiigi
I assumed that the Docker concept is built according to the scheme, where ENTRYPOINT is a full-fledged deferred commit, and not just part of the metadata for CLI docker run.

RUN commit ___ RUN commit ________ENTRYPOINT init commit____________merged  _________RUN entrypoint commit
                        \____ CLI docker run (mount, env, net) commit___/

where in the entrypoint commit the command is only initialized, but not run. RUN entrypoint which records the execution of the entry point after merging commits.

Where could be implement additional script (privileged) as additional RUN commit between merged commit and RUN entrypoint commit

But these are just thoughts out loud.

docker run - I mean docker create

from moby.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.