• 0 Posts
  • 23 Comments
Joined 2 years ago
cake
Cake day: July 12th, 2024

help-circle

  • I feel like I read the exact same story (Person discovers docker group is effectively root because llm agent used it to circumvent not having sudo) a few minths ago. (Not saying you stole it, two people can have the same experience independently of each other. I just found it interesting that this is, apperently, such a commonly overlooked issue.)

    Also, this is documented:

    Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless mode, and you should therefore be aware of some important details.

    First of all, only trusted users should be allowed to control your Docker daemon. This is a direct consequence of some powerful Docker features. Specifically, Docker allows you to share a directory between the Docker host and a guest container; and it allows you to do so without limiting the access rights of the container. This means that you can start a container where the /host directory is the / directory on your host; and the container can alter your host filesystem without any restriction. This is similar to how virtualization systems allow filesystem resource sharing. Nothing prevents you from sharing your root filesystem (or even your root block device) with a virtual machine.

    https://docs.docker.com/engine/security/#docker-daemon-attack-surface





  • Just out of curiosit, what do you gain from unmounting the fs? Depending on your reasoning, it might he an option to use a zfs filesystem, set it up so automatic jobs rarely run and then set a somewhat agressive disk spin down policy. That way fs info would be handled by the arc, not the disks and they would only spin up when an actual file is accessed.

    At least I assume it would work this way. Look-Ahead reads or your explorer generating previews, etc. might well make thta option fail.





  • For professionals and buisnesses, I see where you are coming from (although there is an argument to be made for prioritizing security over uptime whenever acceptable).

    But for selfhosting/private users? If I wake up one morning and my stuff is not working anymore, I can just roll back to the last good backup and then apply patches manually to see where it goes wrong. Way better to have some downtime when I don’t notice (i.e. don’t need the service) than having open vulnerabilities when a fix exists.