When using Guild Operators tools for installing Cnode and making it run as a service by default the user who runs those scripts is also used to run the services.
This is not optimal and needs to be considered by the admin who sets up the node.
Risk behind it: This user is typically also used to login. Priviledge Escalation scenarios would expose a user which has sudo permissions. Also a bad guy could overwrite your authenticated keys.
Now my question: How did you manage to run it as a sytem user (no login, no sudo)
I see 2 options:
Option 1: Run the installation with your login user. Then change ownage of the folders and switch the service users to a new one. The problem with this is, that the new user is missing some variables since the pre-reqs were installed with the initial user. Therefore having variables configured in the .bashrc of the other user.
Option 2: Run the installation with a user which is meant to be turned into a systemuser afterwards.
So create a service user which is (at this time a sudoer). Run the installation and service deployment as this user. Afterwards degrade the user (remove sudo priviledge, not allow login, or maybe just re-reacte the user as a system user).
Considerations:
Option 1 seems a little risky to me, because every furhter run of deploy-as-service would, change service ownage back to the user which executes the script.
For Option 2 every futher run of the scripts would require to temporarely give back sudo permissions for the user which also must not be forgotten to be removed after the execution.
In an optimal scenario i would see a Parameter to the ./deploy-as-systemd.sh script which allows to set a user which shall be running those services (currently it just takes the current user $USER). But this would also require to prepare that user accordingly through the script, including definition of path variables, …
Yes, we dont tell users how to setup their OS, neither we go into sshd config, sudoers permissions, PAM or SSSD setup, disk encryption, configuring firewall, ensuring OS patches, etc and this is mentioned in documentation. There are clear prerequisite skills for a SPO, and the tools are not meant to skip or take shortcut to sysops, but only to simplify daily activities.
Hi @rdlrt !
I recognized your response on Github and it is OK and I’m not ignoring this! I valuate your feedback and just want to get the default install more secure. If you are not considering my comment for the Guild scripts itself this is absolutely OK for me. Anyways your approach to presume adequade skills from anyone who operats a pool is understandable for me.
Anyways - This topic is not about improving the scripts (so NOT like the GitHub Discussion).
I want to find out how others approached the service-user switch after a install based on Guild Scripts. Most of the guidelines are mentioning a list of security concerns which I hope most of the admins are concidering. But specifically regarding the service user topic I beliefe many are OK with just running the service not as a root, missing the point that it actually should run with a service user. Since this is not the case after a default installation I’m curious about how others dealt with it.
@Alexd1985 : This is not solving the problem.
I already use VPN + Public Key (stored on externak physical device with fingerprint).
So the SSH login is very well protected and not exposed to public network.
Anyways the CNODE service itself runs with a “normal” user.
If someone finds an exploit in the exposed port of the relay (e.g. 3001) he is in the context of a user which has SUDO permissions. A risk which can be avoided.
Absolutely, there are tons of folks (including SPaaS) who prolly even run their servers using a template without considering good sec ops, which is scary. The guild doco (as intro page mentions) does not go into teaching how-to-linux, but points to pre-requisite skillset from official doco an average stake pool operator is expected to be aware of.
For almost every topic from sec-ops point of view , there are pros and cons involved of how user sets up and actually used his system. But if we try to start teaching Linux and networking basics, we wouldnt be able to :
Satisfy every sec-op requirement (since they contradict each other based on usage)
Guarantee the list is inclusive and prevents user from any threats - on the contrary, they make an alert at multiple locations highlighting in RED that they dont.
Spoon Feed steps to a user who will never end up learning linux.
Well, yes and no. Of course this shouldn’t be possible.
Anyways a priviledge escalation attack would try to get into a root shell without according permissions.
But I don’t want to get into details how such an attack would work, I’m not a hacker.
I just want to eliminate any risk by limiting permissions to the minimum required.
And sudo permission for the service User is actually not necessary. Also having a password set for this user is not necessary.
Fully agree. @Alexd1985 - This is something which I mind kind of critical with your guidlines here on the forum. I know that you’re doing this to help people. But there is also the risk of having lots of people just executing the commands without knowing what they are doing
Please do not misunderstand - I really like that you compiled this together and know that you are doing this to support the community!
Well lets see it this way. Better they run the security steps from your guide, then not
I find the idea of limiting the incoming IPs interesting. It’s a valid approach but would not work with the topologyUpdater. But i think it would be OK to freeze a static topology and just update it when some node went offline. UPDATE: Actually rethinking this. How would you know who selects you as a relay to connect to? This would work for outgoing connections but limiting the ingoing would propably limit how useful my server is for the overall network.
But please let’s focus back on the original question: How to switch the services to a service user.
After playing around with this for some time I realized that Option 1 is not working out because all the compiled binares are not available for the fresh user.
Option 1 (Just switch service user to a new system user)
Created a new system user
Switched Files ownage of /opt/cardano/cnode to new folder
changed service to be running with the new user
tried to start the service
→ Environment Variables missing
Copied and run .bashrc from the initial user
cardano-cli not available (cabal bin path in other user)
Decided to cancel this approach and try the other option
The Option 2 worked out for me in the following way
Option 2 (Create a new user for login and degrade the original installation user to system user)
Created another Login user NEWUSER and make it sudoer
Just run any Script as the ORIGINALUSER
Downgrade the original user to not be a sudoer, dissallow ssh access, remove authorized_key
This way everything runs as it was before, just sudo permissions are gone for the service user. Only the new login user has sudo permissions and runs Guild Scripts in context of the original user (otherwiese they would not work because all the binaries and environment variables are not available for the new user.
I also tried to get it the scripts running with the new user withouth needing to impersonate as the original user. But there I ended up with running pre-reqs as the other user and still haven’t had the binaries around in my path. Potentially fix-able but i found the above described approach simplier and less redundant.
Anyways if I want to change something in the future (run prereqes again or re-reploy service) will need to temporarely re-assign sudo permissions to the original user.
#Create another Login User which you will use in future for maintenance SSH Connections
sudo adduser maint-user
#Make the new user a sudoer
sudo usermod -aG sudo maint-user
#Impersonate with the new user
sudo su - maint-user
#Configure appropriate login mechanism (re-do what you did for yor original user, e.g. authorized_key for Public Key Auth), in my case copy the old authorized_key
mkdir -p ~/.ssh
sudo cp /home/OLDUSER/.ssh/authorized_keys ~/.ssh/
sudo chown -R maint-user /home/maint-user/.ssh
#Set the user as allowed user for SSH
sudo nano /etc/ssh/sshd_config
AllowUsers OLDUSER maint-user
#Restart SSHD
sudo systemctl restart sshd
#Login with that new user through SSH directly
#The new user is now able login and also run commands in context of the original install user
#Please note that the user is not able to run any script in context of himself since the Cardano Binaries and Environment Variables are only available to the original install user
sudo su - OLDUSER
#run gLiveView to verify if everything is fine
/opt/cardano/cnode/scripts/gLiveView.sh
#Exit back go get out to the maint-user again
exit
#Reduce permissions of the user which was initally used to install Cardano and will in future still run the service
#Remove SUDO
sudo deluser OLDUSER sudo
#Delete authenticated_key
sudo shred -uvz /home/OLDUSER/.ssh/authorized_keys
#Unset Password
sudo passwd --delete OLDUSER
#remove old user from ssh_config (note: only maint-user remains)
sudo nano /etc/ssh/sshd_config
AllowUsers maint-user
#Restart SSHD
sudo systemctl restart sshd
This is about an attack point where some attacker tries to break into your relay through the externally exposed Port of CNODE.
If your user runs with more permissions than necessary it’s an un-needed risk.
So short answer: yes
