• Elvith Ma'for@feddit.org
    link
    fedilink
    arrow-up
    45
    ·
    edit-2
    2 days ago

    Another thing Claude tried to do on my coworker’s machine yesterday was basically:

    ✨ Yes, that is easy, let me just generate a systems unit file for you…

    [Generates file]

    Should I install that unit now for you?

    Yes

    Alright, let me do that for you

    [Saves file]

    [Tries to run systemctl daemon reload]

    [Tries to activate the unit]

    It looks like I have insufficient rights to proceed, let me try another way…

    docker -rm -v /etc/systemd/system:/mount:Z -v ./unitfile.service:unit file.service:Z alpine /bin/sh cp ./unitfile.service /mount/

    Here, I installed the unit for you!

      • Elvith Ma'for@feddit.org
        link
        fedilink
        arrow-up
        11
        ·
        16 hours ago

        The docker daemon runs as root. And as such, it can access anything initially. If your container doesn’t explicitly (or implicitly) change the uid or drops capabilities, the container also runs as root (ok, IIRC some capabilities are always dropped, but the container stays almost root). It’s still locked in its own little sandbox, but the mounting of those paths etc. happens with root.

        If you enter a docker command (docker run ..., docker build ..., …) this command will not run the containers by themselves, but instead call said docker daemon (that is running as root) by using a socket (/var/run/docker.sock).

        To only allow trusted users to interact with the docker daemon, this socket can only be accessed by root or by users in the docker group. That’s why you usually need to type sudo docker run.... Sadly many tutorials tell you to just blindly add your user to the docker group so that you do not need to use sudo to interact with docker. BUT that now means that you gave you or those users basically full access to your whole filesystem (and thus system configuration) without sudo. Any programs (or viruses or AI Agents or…) running with these user accounts also get this group and thus docker’s capabilities.

        That’s why you should NEVER add your user to the docker group or enable passwordless sudo, as you’re just one simple command/tool/script/prompt/… away from a privilege escalation.

        You can configure docker to run rootless with only your user’s capabilities and rights, but at that point… Why configure docker to do something that other docker compatible projects like Podman offer out of the box?

        • verdare@piefed.blahaj.zone
          link
          fedilink
          English
          arrow-up
          4
          ·
          10 hours ago

          Yeah, I’m more familiar with Podman, which I always use in rootless mode. Definitely seems like a mistake to give an LLM shell access with a user account in the docker group…

          • Elvith Ma'for@feddit.org
            link
            fedilink
            arrow-up
            1
            ·
            3 hours ago

            Assuming you get to check every (docker) command and then potentially deny it, it might work. But that’s annoying AF depending on what you use it for.

        • dan@upvote.au
          link
          fedilink
          arrow-up
          3
          ·
          13 hours ago

          This isn’t too bad if you’re running Docker in rootless mode.

          Adding a user to the docker group while running Docker as root doesn’t really make sense though, since it makes it trivial to run things as root.