Run pipeline as nobody
nneonneo opened this issue · comments
A lot of posters are rightly worried about the safety risks. Why not just run the pipeline as a nobody user? Pipelines should be textual manipulations by default, so they don’t need any filesystem permissions.
For extra security, you could unshare networking to avoid accidental network access, although that seems less likely to occur entirely by accident.
How can I do the "run as nobody" thing??? It's the third time I see it mentioned already, but never heard of such a thing before, so don't really know where to look for any explanation... would you care to share some good links or something? TIA!!!
The easiest way would probably be to deploy a helper script (wrapper) which is setuid/setgid nobody (you could verify this on each startup if you’re paranoid) and run all pipes through it (e.g. cat content | helper “pipe | pipe2”). Although this means you need sudo to install UP, you will not need sudo to run it.
Just wanted to leave my 2 cents on the subject of preventing users from shooting themselves in the foot... Possibly setting up a syscall blacklist/whitelist is a possible way to go? For instance, blacklisting sys_unlink for any commands run could provide an adequate possible safety net.
Alternative idea: start the up process in a container.
@j3k0 no. containers do not provide secure isolation unless the engine specifically configures it that way. This is why even Docker itself recommends to drop privileges inside the container.
@dev-zero Of course you shouldn't run up (or anything) as root inside a container. Anyway, my suggestion is more about protecting yourself from wiping off part of your hard drive, deleting network interfaces or modifying anything in the host system "accidentally".
You can mount the host drive as read-only inside the process's container if needed, or not even mount it, just run inside a minimal posix environment.
I've implemented a "Press Enter to run" feature as a safety measure in just released v0.2 / v0.2.1.
For sketching potential alternative approaches for future, I added a wiki page, as described in more detail in #8. Based on this, as for now I will close this issue. I believe the "Enter" functionality is mostly good enough. Let's try to live with it for a while and see if it works for us. If you find it limiting after trying it for some time, please come back here and reopen this issue, or submit a new one referring to it. I'm kinda tempted to try the seccomp approach, but I'm trying to restrain myself, also based on respect for the fact that the "Enter" functionality seems good enough and is very KISS. And there are quite a lot of other interesting ideas to consider for potential development of up, while my time and resources are super limited.
Thanks a lot for great ideas and discussion!
So it's honestly probably not very useful in this case, but just for the sake of learning I'm gonna leave a link to this blog post talking about OpenBSD's pledge syscall since I think this is kinda the sort of thing that pledge is supposed to help with