nodejs should not run as root

[QQHeresATissue]

As the service is intended to be outward facing, a vulnerability in the hosted content would allow an attacker to execute commands under the context of root. I am not familiar with nodejs, but it looks like there are a few options to switch to a less privileged user after execution.

[hexparrot]

True of any service that runs as root, but it is a necessity for MineOS based on the Linux authentication model it offers (i.e., using Linux usernames and passwords).

If MineOS doesn't run as root, it can only offer a single login and there would be no permissions possibilities when connecting to the filesystem (so you couldn't separate users from any servers like you can right now).

It's true, many users don't use more than one login (since they are the sole user), but there are also many users that do--and it is baked into the design of MineOS. In current incarnations of MineOS, it is unavoidable to use root.

So yes, in theory a vulnerability would allow an attacker to execute commands--and you've seen instances of this in such high-profile cases as shellshock--a piece of software on literally every Linux box (and was running as root)...but sometimes you just have to accept some services run as root and keep them updated.

Alternatively, you can use MineOS-on-Docker for the process isolation you desire. Docker is a lot more involving than any other setup, so while it is offered, there's only so much support you can get unless you have a decent grasp on using the software already.

[QQHeresATissue]

True of any service that runs as root, but it is a necessity for MineOS based on the Linux authentication model it offers (i.e., using Linux usernames and passwords).

This is why most services hand off to a lesser privileged user once a low port socket has been established (assuming it is required).

If MineOS doesn't run as root, it can only offer a single login and there would be no permissions possibilities when connecting to the filesystem (so you couldn't separate users from any servers like you can right now).

Without further modification to authentication handling sure. There is no reason that the user accounts couldn't be stored elsewhere rather than read from /etc/shadow. This could also provide better user handling since one would not need to restrict an account in linux just for the sake of having an account in the interface.

It's true, many users don't use more than one login (since they are the sole user), but there are also many users that do--and it is baked into the design of MineOS. In current incarnations of MineOS, it is unavoidable to use root.

All the more reason to have separation of privilege.

So yes, in theory a vulnerability would allow an attacker to execute commands--and you've seen instances of this in such high-profile cases as shellshock--a piece of software on literally every Linux box (and was running as root)...but sometimes you just have to accept some services run as root and keep them updated.

To simply accept that other vulnerabilities have existed, and see the fallout caused by them, then dismissing it baffles me. The expectation that something will be mitigated in a timely manner requires that the vulnerability be disclosed.

Alternatively, you can use MineOS-on-Docker for the process isolation you desire. Docker is a lot more involving than any other setup, so while it is offered, there's only so much support you can get unless you have a decent grasp on using the software already.

Not sure what that is, but if adding another layer of security or mitigating the requirement to run as root, why is it not the default?

[hexparrot]

This is why most services hand off to a lesser privileged user once a low port socket has been established (assuming it is required).

You'll notice that any service that hands off to a lesser privileged user does not ever write to the filesystem from that process. So...Apache web server, nginx, lighttpd... yes, none of these generate files like Minecraft. None of these require user logins that would be purposefully able to log in as Linux users.

Without further modification to authentication handling sure. There is no reason that the user accounts couldn't be stored elsewhere rather than read from /etc/shadow. This could also provide better user handling since one would not need to restrict an account in linux just for the sake of having an account in the interface.

Yes, it is 100% entirely possible that the accounts could be stored elsewhere, but then also you couldn't use the secure and hardened utilities that already allow easy access to read and write to the underlying filesystem. So great, the usernames and passwords come from... /etc/mineos_passwords and suddenly the process owner of the webui is "mineosd"--and through what means are you logging in with SFTP to upload or download Minecraft files? None, because now I would be required to also write in a privilege system not only that applies to logins, but also to filesystem access.

So in short, a non-root process owner of the webui makes 100% of file upload/download be built into nodejs. Should you ever try spearheading an open-source project on your own, you'll understand the overwhelming undertaking that would become.

To simply accept that other vulnerabilities have existed, and see the fallout caused by them, then dismissing it baffles me. The expectation that something will be mitigated in a timely manner requires that the vulnerability be disclosed.

You know what your system is still doing? Running your openSSH server as root.

I guarantee it. Do you know why?

Because some services' convenience and utility are so overwhelmingly undermined with those extra layers of security. Security isn't black and white--secure or insecure--it is a trade-off. You could, for example, have pretty much zero internet-facing services run as root--and that would be SECURE, but you do not, because you know that the usefulness of the applications veer toward none when the security measures in place inhibit the ability to leverage them in practice.

Not sure what that is, but if adding another layer of security or mitigating the requirement to run as root, why is it not the default?

Because after over half a decade working on this project, I have learned the level of Linux-competence the average Minecraft server-hopeful is not able to handle the extra layers of security that theoretically and practically protect them, but practically will 100% keep them from being able to use the software at all. This project--if you are at all involved in the community--is solely run by me. And while there are other projects--commercial ones at that--who are also run by only a sole dev, you'll notice the stark difference that I cover far much more than "how to install it on your system" and taking feature requests, but in fact I cover, document, and instruct on how to use almost all aspects of Linux/BSD.

So no, I chose not to make thousands of young Linux-novices also have to learn the nuances of Docker in order to run a piece of software aimed to encourage and instill an early affection for a non-gui operating system.

So, while extra-millions of users were exposed to shellshock, a much smaller minority were adversely affected. And while only thousands of people are exposed to exploits that could affect MineOS, I do my due diligence to keep my software updated and educate my users. If you really find it so baffling that nodejs could run as root that you question my entire design, I welcome a pull request; you can reach me on the forums or email for nodejs help--because I try to help users on every facet of *nix, and simply just don't have the time to design and implement the world's most inherently secure server front-end.

[MrTechGadget]

Well said William. I for one don't make the Webui directly accessible via the Internet. Any admins would need to VPN into the private network to administer the server. So that NodeJS is running as root wouldn't matter.

Also, if I wanted to provide secure access to the WebUI, I would only do so through a hardened reverse proxy like nginx or others.

On Sunday, April 10, 2016, William Dizon notifications@github.com wrote:

This is why most services hand off to a lesser privileged user once a low port socket has been established (assuming it is required).

You'll notice that any service that hands off to a lesser privileged user does not ever write to the filesystem from that process. So...Apache web server, nginx, lighttpd... yes, none of these generate files like Minecraft. None of these require user logins that would be purposefully able to log in as Linux users.

Without further modification to authentication handling sure. There is no reason that the user accounts couldn't be stored elsewhere rather than read from /etc/shadow. This could also provide better user handling since one would not need to restrict an account in linux just for the sake of having an account in the interface.

Yes, it is 100% entirely possible that the accounts could be stored elsewhere, but then also you couldn't use the secure and hardened utilities that already allow easy access to read and write to the underlying filesystem. So great, the usernames and passwords come from... /etc/mineos_passwords and suddenly the process owner of the webui is "mineosd"--and through what means are you logging in with SFTP to upload or download Minecraft files? None, because now I would be required to also write in a privilege system not only that applies to logins, but also to filesystem access.

So in short, a non-root process owner of the webui makes 100% of file upload/download be built into nodejs. Should you ever try spearheading an open-source project on your own, you'll understand the overwhelming undertaking that would become.

To simply accept that other vulnerabilities have existed, and see the fallout caused by them, then dismissing it baffles me. The expectation that something will be mitigated in a timely manner requires that the vulnerability be disclosed.

You know what your system is still doing? Running your openSSH server as root.

I guarantee it. Do you know why?

Because some services' convenience and utility are so overwhelmingly undermined with those extra layers of security. Security isn't black and white--secure or insecure--, it is a trade-off. You could, for example, have pretty much zero internet-facing services run as root--and that would be SECURE, but you do not, because you know that the usefulness of the applications veer toward none when the security measures in place inhibit the ability to leverage them in practice.

Not sure what that is, but if adding another layer of security or mitigating the requirement to run as root, why is it not the default?

Because after over half a decade working on this project, I have learned the level of Linux-competence the average Minecraft server-hopeful is not able to handle the extra layers of security that theoretically and practically protect them, but practically will 100% keep them from being able to use the software at all. This project--if you are at all involved in the community--is solely run by me https://github.com/hexparrot/mineos-node/graphs/contributors. And while there are other projects--commercial ones at that--who are also run by only a sole dev, you'll notice the stark difference that I cover far much more than "how to install it on your system" and taking feature requests, but in fact I cover, document, and instruct on how to use almost all aspects of Linux/BSD.

So no, I chose not to make thousands of young Linux-novices also have to learn the nuances of Docker in order to run a piece of software aimed to encourage and instill an early affection for a non-gui operating system.

So, while extra-millions of users were exposed to shellshock, a much smaller minority were adversely affected. And while only thousands of people are exposed to exploits that could affect MineOS, I do my due diligence to keep my software updated and educate my users. If you really find it so baffling that nodejs could run as root that you question my entire design, I welcome a pull request; you can reach me on the forums or email for nodejs help--because I try to help users on every facet of *nix, and simply just don't have the time to design and implement the world's most inherently secure server front-end.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/hexparrot/mineos-node/issues/183#issuecomment-207988865