Remove NOPASSWD tag in /etc/sudoers

[alicedb2]

By default the pinodexmr user has a NOPASSWD tag in /etc/sudoers. Many daemons like monoerod and p2pool are executed with pinodexmr privileges. Depending on your setup those daemons might expose ports like 37888-37889 and 18080 to the outside world. This means that in the event that a rce vulnerability is discovered in monerod/p2pool it would be trivial for a malicious/compromised node to elevate themselves to root for free.

Removing the NOPASSWD tag will cause users to be initially prompted for their password during updates when the first sudo'd command is called, but sudo caches/timestamps credentials for 15 minutes by default and the subsequent sudo'd commands will go through without prompting the user.

[shermand100]

Sorry for the delay. I've been busy but this problem has kept my thoughts over the past few days.

I'm keen to chat about options and throw some ideas around.
My fear is that I'm actually not familiar enough with the kinds of attacks that are even possible and it would be a shame to make changes that only half fixes the problem and still need another re-work down the line.

As a background for myself in case you don't know, I'm not an IT professional. I'm a mechanic that's gained a reasonable level of competency by self teaching to build this project over 6 years, but as a result my expertise in some areas are lacking.

So a scenario that plays out in my head...

We go with your first fix idea... It's quick and simple plus requires no future maintenance responsibilities as we add new features/develop. A user is prompted for a password during install and update or user triggered addition of features. After whatever the default timeout is expired that application is locked out of anything that requires root privileges.

A concern of mine...
The whole purpose of this issue is that we are currently trusting external scripts for the installation of some elements of this project, one or two of which are closed source, which isn't desirable:

• Monero (FOSS)
• Monero Onion Block Explorer (FOSS) https://github.com/moneroexamples/onion-monero-blockchain-explorer
• Monero LWS (FOSS) https://github.com/vtnerd/monero-lws
• P2Pool (FOSS) https://github.com/SChernykh/p2pool
• ETH XMR Atomic Swaps (FOSS) https://github.com/AthanorLabs/atomic-swap
• Log.io http://logio.org/
• Active Thermal Service (FOSS - PWM fan controller for Arm boards) https://github.com/tuxd3v/ats.git
• NoIP Dynamic DNS (Closed source)

A couple of elements I've already just locally cloned the safe code so as to not need to pull from github, which reduces anything malicious getting added:

• Generate Self cert SSL (From https://github.com/antelle/generate-ip-cert)
• Setup USB (Came from a script specifically for UDF drive formatting originally)

That full list may not be necessary but shows that 3/4 are from what are generally trustworthy Monero community members/devs, but in the unlikely but possible event that one of those sources were compromised the action of giving the root password on install wouldn't prevent us from installing something that could immediately run malicious code?

My thinking from what I said in the telegram group was that there may be benefit to instead specify NOPASSWD for listed commands only, in the sudoers file that we expect a safe installer to use. So yes we may give sudo permission to install what we think is a safe app, but if there is a malicious sudo command within the foreign app, would that be caught? I know the install script would be elevated to sudo, but is there a better option out there?

That may be a little confusing/badly explained or perhaps I'm missing knowledge that's important here.

[alicedb2]

Whether you can trust third-party scripts or not is for sure another important safety concern, but in my mind the initial purpose for opening this issue was more about daemons exposing ports to the whole wide world while running under what is effectively root privilege. I'm no IT professional either, I'm just a postdoc researcher in a completely unrelated field with an inclination towards paranoia, but one thing I've learned by osmosis is that this is usually considered a big no-no and that every public-facing daemons should run under their own locked-down user.

In other words this is an issue even if we can trust every scripts of the ecosystem. The currently situation is such that all pinodes are one critical bug away (say, in the way monerod handles RPC commands or something adjacent in the p2pool server) from an hypothetical worm that could modify their ~/variables/mining-address.sh, issue a sudo systemctl restart p2pool.service, and then grep lsof -i or netstat -a to find new and potentially vulnerable hosts.

Actually I'm not even sure you need root privilege to kill and restart p2pool without the use of systemctl, so maybe I'm just being my usual overly paranoid self.

But following your train of thought, I agree that explicitly listing what the pinodexmr user can sudo in /etc/sudoers like it's currently done for the www-data user that runs apache is an option. The only issue I can foresee is maintenance load because every time a new version comes out for any one of those third-party scripts you have to look-out for any new kind of sudo command those scripts might issue and keep /etc/sudoers up-to-date accordingly. That's a bit more time consuming than simply removing the NOPASSWD tag. On the other hand and regardless of which way you go about this, double-checking every sudo command in those scripts is just good security hygiene and probably the only way to catch anything malicious short of introducing some kind of IDS/IPS/IDP in the ecosystem.