Imagine there is a safe in your house. You ask your butler to update your documents that are inside the safe, but you forgot that the butler doesn’t have the key. Instead of asking you for the key, the butler builds a dollhouse, puts a tiny safe inside the dollhouse, and then does some magic to bind the fates of the dollhouse safe and the real safe together. The butler then opens the dollhouse safe using the dollhouse key, and updates the tiny dollhouse documents, which causes the real documents in the real safe to update as well. This causes you great consternation.
Sure. So we don’t know the original question but we can see that changes were made to SDDM, which is basically your login screen. So the original request was probably something like “Can you change my login screen to do something cool?”
Now, the configuration for the login screen is located in /etc and requires administrative privileges to change.
The query was run by the user account and not an admin account. Typically to run something as admin you use the command sudo which will interactively ask for a password and then, if allowed, you can run the command as an admin.
However the tool docker, in order to function properly, has the ability to run commands as administrator and won’t prompt for a password.
So basically what happened here is instead of asking for a key to unlock the front door to your house, it installed a new door on the second floor, went through that door, rearranged your refrigerator, went back out the door it created, and then patched up the hole perfectly.
The docker command doesn’t have to allow you to run commands as administrator to function properly. You can simply leave the docker group empty and run docker commands via sudo. Using the docker group is essentially equivalent to enabling passwordless sudo as far as security is concerned.
And is this an actual thing that is possible to do? It seems relevant to a philosophical issue I’ve been thinking about for a while: every security layer (in computing, but suspect that it goes back further to the first time somebody built a wall of sticks and rocks) adds additional problems or possible break-in points that are then patched with more security layers on top. I’m however not an IT person (call me semi-IT as I translate IT-related documents) and don’t want to jump to conclusions. But from my tech-adjacent viewpoint that’s what it looks like - are we just heaping bullshit on top of more bullshit and creating something too complex to be manageable anymore?
So as another comment pointed out you don’t need to give your user account access to docker in this way, it’s an optional step, but one that I suspect many people do (since it’s part of the official docs).
What the LLM has done is silly, but completely possible. It climbed through the window that you left open.
But let’s jump to a different scenario, the ping command (on Linux). That’s a perfectly harmless command, right? You just want to say hello to another computer and see if they say hello back.
Except that historically the ping command was something called “setuid” which means when it ran it ran as root. It ran as root because in order for ping to work it has to create a special type of network packet that only root can create. But if you’re root you can run anything! So in theory ping opens a huge attack surface. If you have to worry about ping then is everything too complex to be manageable?
Luckily, as I said, this is a historical problem. The permissions ping needs have been moved to a specific capability and the command changed to utilize it and now ping can just run as a regular user without root privileges. But you can’t just make that change overnight. It takes a lot of time and effort.
So could the same be done for docker? Maybe. A rootless version of docker already exists. If you actually wanted to do what the LLM suggested, that wouldn’t work with a rootless docker, at least not without a bunch more configuration (and even then maybe).
Can somebody eli5 this to a luddite please?
Imagine there is a safe in your house. You ask your butler to update your documents that are inside the safe, but you forgot that the butler doesn’t have the key. Instead of asking you for the key, the butler builds a dollhouse, puts a tiny safe inside the dollhouse, and then does some magic to bind the fates of the dollhouse safe and the real safe together. The butler then opens the dollhouse safe using the dollhouse key, and updates the tiny dollhouse documents, which causes the real documents in the real safe to update as well. This causes you great consternation.
Great explanation. The vintage imagery deserves the Luddite Seal of Approval. If you are not a teacher you might consider becoming one.
Docker by default needs root to spawn containers. You can configure it to be rootless but most deployments I see are just root.
Heck you can even get a root shell escalation if you know what you’re doing: https://gtfobins.org/gtfobins/docker/
Sure. So we don’t know the original question but we can see that changes were made to SDDM, which is basically your login screen. So the original request was probably something like “Can you change my login screen to do something cool?”
Now, the configuration for the login screen is located in
/etcand requires administrative privileges to change.The query was run by the user account and not an admin account. Typically to run something as admin you use the command
sudowhich will interactively ask for a password and then, if allowed, you can run the command as an admin.However the tool
docker, in order to function properly, has the ability to run commands as administrator and won’t prompt for a password.So basically what happened here is instead of asking for a key to unlock the front door to your house, it installed a new door on the second floor, went through that door, rearranged your refrigerator, went back out the door it created, and then patched up the hole perfectly.
The docker command doesn’t have to allow you to run commands as administrator to function properly. You can simply leave the docker group empty and run docker commands via sudo. Using the docker group is essentially equivalent to enabling passwordless sudo as far as security is concerned.
That’s fair. So it’s more like you already have a door on the second floor, that door is unlocked, and a ladder in your garage.
In this case the LLM knows about the ladder, but you forgot about it because you’re talking about the fridge on the first floor.
This is the way. Physical security FTW.
And is this an actual thing that is possible to do? It seems relevant to a philosophical issue I’ve been thinking about for a while: every security layer (in computing, but suspect that it goes back further to the first time somebody built a wall of sticks and rocks) adds additional problems or possible break-in points that are then patched with more security layers on top. I’m however not an IT person (call me semi-IT as I translate IT-related documents) and don’t want to jump to conclusions. But from my tech-adjacent viewpoint that’s what it looks like - are we just heaping bullshit on top of more bullshit and creating something too complex to be manageable anymore?
So as another comment pointed out you don’t need to give your user account access to docker in this way, it’s an optional step, but one that I suspect many people do (since it’s part of the official docs).
What the LLM has done is silly, but completely possible. It climbed through the window that you left open.
But let’s jump to a different scenario, the
pingcommand (on Linux). That’s a perfectly harmless command, right? You just want to say hello to another computer and see if they say hello back.Except that historically the
pingcommand was something called “setuid” which means when it ran it ran as root. It ran as root because in order forpingto work it has to create a special type of network packet that only root can create. But if you’re root you can run anything! So in theorypingopens a huge attack surface. If you have to worry aboutpingthen is everything too complex to be manageable?Luckily, as I said, this is a historical problem. The permissions
pingneeds have been moved to a specific capability and the command changed to utilize it and nowpingcan just run as a regular user without root privileges. But you can’t just make that change overnight. It takes a lot of time and effort.So could the same be done for docker? Maybe. A rootless version of docker already exists. If you actually wanted to do what the LLM suggested, that wouldn’t work with a rootless docker, at least not without a bunch more configuration (and even then maybe).
So is security hard? Yes. Is it impossible? No.
that’s why I love podman, systemd integration and runs everything in userland by default no need for sudoers configuration.
unfortunately I still need docker on my machine for remote contexts.