Recent update to Debian install script

General
1

Background

The additional security recommendations at the end of the installation script now look like this

image
image861Ă—219 5.44 KB

The script now automatically runs node-red admin init and then sets ownership of settings.js to root:root (0:0)

image
image845Ă—197 10 KB

Problem

1

If you follow the advice and remove the 010_pi-nopasswd file and subsequently run `node-red admin init` (eg to change the username/password or enable projects), it runs through all of the questions before finally failing with 
Error: EACCES: permission denied, open '/home/pi/.node-red/settings.js'

(because the user no longer has write permission for settings.js)

2

If you attempt to get around this by running `sudo node-red admin init` the first prompt is

image
image587Ă—161 7.77 KB

If you fail to notice the significance of this and press on through the script, finally you see

Settings file written to /root/.node-red/settings.js

Start Node-red and the settings file just created is of course not used.

image
image763Ă—224 7.18 KB

It is possible to envisage a test for sudo in node-red admin to avoid #2 but this whole situation arises because of the demonstrably useless chown 0:0 settings.js

2

We can certainly undo that change - but it's "demonstrably useless" in the same way that people wearing seat belts still die in car accidents, so we should remove them.

1 Like
3

Can you please explain this statement for clarity.

4

Node-red is a powerful multi-purpose programming language.

Password protecting it is a viable, minimal, security change because once someone can create and deploy flows they can do whatever they want.

Removing passwordless sudo access is also a sensible precaution because it limits Node-red's ability to change system files.

It is a good idea to protect settings.js from malicious changes.
A malicious Node-red user can change or delete any security precautions in settings.js. They can change the user account and password, decrypt credentials, allow function nodes to load external modules, remove any proxy or middleware options specified there.

And after chmod 0:0 settings.js they can make it writable and still do all of the above.

chmod 0:0 settings.js is "demonstrably useless" because I have shown you a simple flow that, without using sudo, can reverse it.
I have also shown how you can prevent this, but it requires changes to the core code.
Someone, perfectly reasonably, chose not to include this precaution in NR v4.

In your analogy, chmod 0:0 settings.js is the equivalent of fitting a car with tissue paper seatbelts.

I will send you the details by PM.

5

The point of this thread was to point out that the advice given at the end of the installation does not work.
I really don't want to revisit questions of Node-red security.

6

Today I stumbled upon the Linux command chattr (and lsattr, both available on Debian at least) which among other options, can be used to make a file immutable even by the superuser.

From man chattr :

image
image940Ă—191 17.6 KB

At first sight, this might be appropriate advice at the end of the install script:

echo "  - After running Node-RED for the first time, prevent changes to the settings file"
echo " "
echo "                   sudo chattr +i ~/.node-red/settings.js"
echo " "
2 Likes
7

Nice find. Certainly worth testing to see if is less “ demonstrably useless”