Give browser and wine ownership to user "nobody" = "foolproof" against viruses?
Title. Just had this baseless yet possible idea on my head and I'd like to know how wrong it is? Since afaik, "nobody" has absolutely zero permissions... other than the ones given by the user.
Pretty sure I'm missing something vital or important, but... I'm completely fine being called dumb every now and then.
Nobody is not a special user like root, it's a regular user that just happens to not have permissions on anything. It can still read everything, write everywhere it's 0777, use /tmp. It's no different than making a new user, except that one by convention isn't used. You shouldn't run things as that user, as that eventually just makes it the user that runs everything. It's supposed to be used by NFS and you should always prefer making a new user instead.
I would just use a rootless container, that way the whole system is invisible to wine apart from the tiny slice of files you mounted in it.
For a second I really thought there was "something else" behind the "nobody" user -- considering its a "typically suggested" user to be used within docker containers (even in some "known" commands/Dockerfiles). So all I need to do then to create a user with the least amount of privileges is to not give it a home directory and a shell? Eh.
Yep, pretty much. I mean I guess it makes sense for containers because the only thing running there is that app anyway, although most good containers set up their own user. For example, the node container has a node user with ID 1000 which is more typical for Linux systems. Docker in particular is often used by Windows/Mac users that aren't necessarily familiar with the ins and outs of Linux and just want it to work, which in a container, is usually fine. With rootless containers, even root in the container is basically useless anyway because it truly runs as a fake ID on the host.
But yes, even in the Linux circles, there can be dubious advice or just bad habits. The thing with doing things right is it takes a lot of time, and sometimes, you really just want to make it work. Just look at how many people just sudo whatever whenever they get a permission error instead of getting into udev rules or whatever. Especially with the growing interest in Linux thanks in huge part to Valve and Proton, I've seen very dubious habits of "just make it work" being ported over from Windows. Those guides are appealing too: one will give you 3 sudo commands, the other will do it proper but then you have a dozen commands or two to set up users and grant permissions and whatnot. The second guide, although the better one, isn't as appealing as the first one especially when you're lost, you just want the thing to work, and you're looking for simplicity.
For a lot of simple use cases, dropping privileges to nobody is simple and easy, no need to create new users. It's not horribly insecure and it's better than root/your own user in terms of blast radius. If there's just one service occasionally running as nobody, it's really no big deal, you just shouldn't run everything as nobody. Plus, people have the tendency of not reevaluating their problem when it grows, so it may start with a simple web server that doesn't need anything, but then you start needing to do more, and the "run the web server" part is mentally marked as done and final, so people will start granting nobody access to more things instead of taking a step back and reevaluating and upgrading their service to a dedicated user with dedicated privileges. Then that leads to privilege creep for a user that's supposed to have none.
The main issue with running more than one thing as nobody is, on Linux, users have the ability to debug their own processes. So maybe your app running as nobody gets exploited, but since you also run NGINX as nobody, now they can hook NGINX and dump TLS certs from it even if the actual files are owned by root and it dropped privileges: it still needs to have it in memory to operate, it loads the certs as root then drops privileges.
It's a great idea, basically the goal of using docker or snaps. Linux containers attempt to strip processes of privilege except what they need to function. You can't get away with giving zero permissions unless you want to give up saving files and using graphics hardware... Which is kind of necessary for a web browser.
executable ownership doesn't matter, what matters is the rights of the user running the binary, and whatever sandboxing you have configured. So use Flatpak or Firejail.
If you're looking for some way to restrict what a few specific programs can do without going to containers, consider firejail. It will likely do a better job than a home-rolled solution.
A process owned by any user will be able to exploit a userspace vulnerability, whatever this user is.
Selinux, chroot, cgroups/containerization add a layer of protection to this, but any vulnerability that bypass these will be as exploitable from nobody as from any other local user.
It will protect a user files from some access attempts but will fail to prevent any serious attack. And as usual when it comes to security, a false sense of security is worse than no security at all.
Remember that some exploits exist that can climb outside of a full-blown virtual machine to the virtualisation host, finding a user escalation vulnerability is even more likely.
The only real protection is an up-to-date system, sane user behavior and maybe a little bit of paranoia.