-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oasis-node should refuse to run if uid/euid is 0 #4464
Comments
What about just showing a big warning if sanity/security checks fail (i.e. running as root, permissions on data dir)? And delaying the startup for a few seconds to encourage checking of the logs? And there should be a flag to enable/disable such behavior? For example in an isolated VM or an isolated Docker container (with strict seccomp and apparmor profiles) running as root or not is not important anymore. (Sidenote: In Qubes OS, one of the most security-focused desktop OSes, every qube VM runs apps as a user with password-less sudo permissions. This is not considered a security issue, because security is achieved by isolating VMs at the Xen level.) |
People don't read warnings (or errors for that matter). There is a generic "if you enable this, it's your own fault if something horrible happens" config option, that "not terminating the node" can be gated behind. I suspect the number of users that are running the node as root incorrectly will forever outnumber the users that do it correctly. |
Agreed. We should gate running |
While I know that there are some people that are doing this, it is a really bad idea and violates the principle of least authority. There is absolutely nothing in the node binary that requires root (or any form of elevated privileges).
I would be open to making the user provide a non-root account in the config and using setuid to drop privs (since this is possible as of Go 1.16), this does not work for the oasis-node binary in particular because
syscall.AllThreadsSyscall
is incompatible with programs that use cgo, and someone decided to enable badger's use of jemalloc in our production builds.If it were up to me, implementing this feature would make the node terminate immediately if ran with elevated privs, though I am sure people will complain about it, even if it is something that should never be done.
The text was updated successfully, but these errors were encountered: