> I always make my user part of the docker group, so my NixOS also has this, and any Ubuntu I’ve used over the past year.
You may do that, but I don't. I always use sudo to manage the few docker containers I need, and I prefer podman where possible specifically because I can run it rootless.
If you want to give your user passwordless root for convenience, go ahead, but that should never be the default.
> I always use sudo to manage the few docker containers I need
I'm afraid that isn't really any better. If the attacker is in position to exploit membership in the docker group, he already has access to the user's .bashrc. He can simply write a function called sudo that wraps the real command and records your password[1]. Unless the user always invokes sudo with /usr/bin/sudo, docker group membership doesn't really make a difference.
Once malware runs as an administrator, getting access to root isn't really that complicated. The boundary between wheel and root is more or less security theater.
Edit: Oh well, I see now that others have made the same point (https://news.ycombinator.com/item?id=49500588). With the same wording even. I'm half-way tempted to delete my comment so as not to look like a plagiarist, but it seems many posters are unaware of the vulnerability, so I'd leave it here.
Does 'chattr +i .bashrc' reliably prevent this? Always seemed sensible to me. Then again, there are a few files getting sourced by the shell and I am not sure I could spontaneously name them all.
The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. A better way would probably be to use `sudo chown 0:0 .bashrc`.
Also you will want to do the same to .profile (because of LD_PRELOAD etc).
And also do the same to any directories in your $PATH (~/.local/bin etc)
You may do that, but I don't. I always use sudo to manage the few docker containers I need, and I prefer podman where possible specifically because I can run it rootless.
If you want to give your user passwordless root for convenience, go ahead, but that should never be the default.