FixPermission script and sudoers
ThHareau opened this issue · 2 comments
Hello,
I'm quite worried about adding the fixpermissions and start.sh scripts to the sudoers file. If someone manage to get access to this repo, this could have a bad impact.
For fixpermissions.sh, I think it would be safer to only have this line in the sudoers file:
minecraft-be ALL=(ALL) NOPASSWD: /usr/bin/chown -R userxname dirname/minecraftbe/servername
I tried it locally and it works fine. Then the rest of the sudo commands can be run without sudo, as long as they are run with the user userxname.
If you are ok with this suggestion, I can start a PR.
For the start.sh script, I don't really understand why this is needed. Do you have any clue?
The server can't restart itself for the daily restart without access to start.sh. sudo systemctl start yourserver will fail without it meaning the server can't reboot itself. If you don't use that functionality you can take it out too. It wasn't in there originally but it was fixed because it broke the daily reboot.
How would someone getting access to this repo cause what you are saying? The scripts do not update themselves. They don't run code from the repository. What risk are you referring to? I've gone through great pains to not make this ever run code from the repository other than during the manual setup process so this is quite a leap here and I'm about to show you how if they can do this you're in way, way worse trouble anyway since they can just write anything they want into the minecraft server scripts and you've just stated your minecraft server user has sudo rights.
If they have access to run start.sh they will be able to start your server without your permission. That is the extent of the damage they will be able to do. start.sh does not download or execute code from this repository. Ever. Only SetupMinecraft.sh does that and you have to run it yourself.
If your server has further vulnerabilities and they are able to somehow fully leverage or "log in" as the minecraft user then you could just write to start.sh, stop.sh or any one of the other scripts to insert your own code in there. That is exactly what I (and they if they were capable of getting this far) would do. How would your method address this? If the user is compromised they can write to the server files right? Then theoretically you add in your own code to do whatever you want, yes?
This is why you don't run the server as root. These are compartmentalization layers. If you set up a minecraft server user then all that can be compromised by that user is the files in the minecraft server directory. If the user doesn't have access to anything else then they won't be able to access anything else.
The minecraft server user doesn't even need sudo rights. If you are this concerned about security that is the first thing you should do. Take away rights from the minecraft server user. That's the point of the sudoers file. We don't care if they start the server without permission because if the server is running it will just exit and would only matter if it's down intentionally in which case you could just rename start.sh. It also doesn't matter if they can run the script to make the minecraft user take ownership of the server files, they might even be doing you a favor! We definitely do care though if they are able to exploit another vulnerability/misconfiguration in your server though to be able to start writing to the minecraft server files, or worse system files / other services via sudo -u if sudo is in the mix.
If they've compromised your server to the point where they can write to files as credentials (this means your server's security has also failed in another way and you're dealing with multiple breaches, you can't just do this even with a minecraft server exploit, you need to escalate using these privileges and this is where things like sudo rights are bad as well as privileges to any other services or files on the entire system) you're way past being able to do anything about this anyways. That's why we use the least restrictive privileges model.
Is your minecraft server a regular user? Or did you make it literally minecraftuser (with a nologin shell)? If you made it a regular user then they will also have access to breach any service that user has access to. If that user has sudo rights they can breach anything. This is where you need to start. Your user has sudo rights? Then your user has root and anyone who hacks you has root. I also sure hope it's a dedicated user, otherwise the changes you are making are almost silly and pointless if you are leaving these doors open.
You also shouldn't assume that everyone's system's default (or customized) sudo configuration will behave the same as yours. I made the same mistake, and we all learned the hard way that is not the case. Different systems come with different default levels of lockdown for sudo. Some of them are much safer and more locked down than your configuration (RHEL and CentOS come to mind) which is honestly a little loose from how you've described it and I could certainly break out of it if I was on there. This is why you don't give them sudo rights. There's tricks with it you aren't aware of as with almost all things Linux (as well as myself, learn new ones all the time and have screwed it up on this project and got corrected a bunch of times).
I'm willing to address any security issues but I don't think we are at that point yet just from how you described your setup. This is not where you need to be focusing your security improvements and need to start with the real fundamentals of least restrictive privileges model here. No sudo rights. No non-dedicated user that has access to anything other than the Minecraft server files. Nologin shell set for the user so it can't log in to the system / get a shell. That is the intended security model for sure. When you set it up this way you know what the worst case scenario breach will be limited to. Thinking that you are ever "secure" enough to not have to set it up this way is a mistake with any system no matter who's name is on it. Everything has exploits found. You need to design your service model according to this very real I.T. universal truth. It can always happen, and you need to prepare and design for that from the bottom up.
If you configure this correctly with a principle of least privilege model (a tried and true industry standard approach) it protects you from so much more than you are realizing you need to worry about here. It widely applies to all services you are running of any kind. This service is even safer because no, it does not download and execute remote code from a server silently. Even for ones that do though using this will compartmentalize any damage or breach to only files/services that were directly in use by the service. The application layer becomes far less important when you think about things this way because to be honest we rarely "trust" the services we are running anyway either (do you trust Microsoft's service to not scrounge your system for analytics/data? you didn't read the EULA or End-User-License-Agreement if you do) and we are protecting ourselves from that as well. Hopefully that helps!
Hi,
Thanks for your answer. You are publicly supposing that my server is not secured, let me clarify the point first: my server is secured, I am having only one user per service, all of them being non - login shells. I was trying actually to evaluate the possibility to run a minecraft server in the same server as other services that I host when I noticed, through the sudo logs that I receive every day, that the chown was not working because run as root when I understood the problem.
If the server does not auto update itself I guess this is indeed not that worrying, the chances that a malicious commit arrive on this repo and that someone execute the update script is indeed low. Even if it's the case, they still have the possibility to check the code in real time.
I'm still having questions: from what I see, three commands are added to the sudoers file:
/bin/systemctl start $ServerName
I totally understand why this is needed, it make total sense/bin/bash $DirName/minecraftbe/$ServerName/start.sh"
Why is that one needed? I see nowhere this being executed as sudo. I thought that running it with sudo was not actually possible?/bin/bash $DirName/minecraftbe/$ServerName/fixpermissions.sh
For fixpermissions I see now that it's not specifically worrying, however, I wonder if it's needed and also if it's actually working. The script is run as root, however I noticed in my logs a few lines as follow:
[myusername] : command not allowed ; PWD=/home/[myusername]/minecraftbe/[myservername] ; USER=root ; COMMAND=/usr/bin/chown -Rv [myusername]/home/minecraft-be/minecraftbe/[myservername]: 1 Time(s)