1

I'm working on a small controlpanel for a hobby project of mine, which is supposed to set up game servers. But I have some concerns regarding security that I would like some input on.

My first idea is to have the controlpanel "remote" (which a web frontend interacts with) running as an user, and when setting up game servers they would all go in a subdirectory of it's home folder, like so:

/home/paneluser/servers/server1/
/home/paneluser/servers/server2/
/home/paneluser/servers/server3/

But then, as users would have FTP access to these subdirectories, they would be able to upload malicious code (i.e. change the executable) so they could easily gain access to files of other servers and for example delete files.

My second idea is to run the controlpanel "remote" as it's own user (root?) which then creates separate users for each server and starts them as the appropriate user.

My third idea is to expand on the first one, and run all servers in some kind of sandbox where where the executables can't access files outside. But I do not technically know how this would be done or if it's even possible.

So what I would like to know is what the best approach would be. Or is there another, better, approach?

5

My second idea is to run the controlpanel "remote" as it's own user (root?) which then creates separate users for each server and starts them as the appropriate user.

This is not the best solution, but in the interest of you learning, I'm going to critique it anyway. I'll get to the best solution in just a second, but this is important.

Repeat after me: never, ever run web-facing services as root if you can help it (and in this case you can help it, because you have control over the application).

The correct way to implement this is to have a daemon that starts as root, but drops privileges to an unprivileged user. You would have this daemon spawn a second daemon before it dropped privileges, and the unprivileged daemon would talk to the privileged daemon. The privileged daemon would then perform actions on behalf of the unprivileged daemon.

Repeat after me: having this kind of privilege separation is USELESS unless the privileged daemon performs validation. That means that you cannot have the privileged daemon blindly accept commands from the unprivileged daemon. It must make sure that the command is something that is OK and makes sense. If you do not do validation, you have introduced a confused deputy problem vulnerability. When writing this kind of security code, assume that your web-facing service will be compromised. I hear what you're saying - "that will never happen". Yes, it will. Security is all about limiting the damage. You may also benefit from reading The Six Dumbest Ideas In Computer Security.

My third idea is to expand on the first one, and run all servers in some kind of sandbox where where the executables can't access files outside. But I do not technically know how this would be done or if it's even possible.

A+: this is (part of) the correct way to accomplish this kind of web application security. The way that you would accomplish this is by spawning your server processes in a chroot jail.

1

I would suggest. each game server run as it's own user.

/home/user1/game /home/user2/game

Then for starting and stopping the game server you just need your webserver to execute a command as that user (user1 or user2).

SFTP is easy to setup when backed by real users.

Personally I would run a deamon as each user that listens for commands on a fifo or tmp file then runs them as the user. Then have the web front end write to that file.

The deamon should only listen for specific commands like "stop" and "start" that execute the game or kill it. This way your separation is in tact, but you can run commands that you as the admin/dev setup.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.