Security Best Practices
Introduction
When hosting a PIFOP Optimization Server you have to be mindful of the potential security pitfalls that you should avoid and how you can avoid them. If you are running an Opt-Server just for yourself or for a few people that you trust, you shouldn't be too concerned. However, remember that people can have their account passwords compromised in a number of ways unrelated to our services. Therefore, this list of best practices is for everyone hosting an Opt-Server.
The reason why this is a list of best practices rather than a list of must-do's is because every command executed by an Opt-Server is isolated within a sandbox, which already offers a robust protection to the host system from most potential threats. Opt-Servers can safely run even programs of untrusted users. If followed, these best practices will make it even safer.
1. Do not create a command to run shell programs,
e.g. /bin/sh and /usr/bin/bash
Unless you know what you are doing, you are probably giving your users more power than they should have.
2. Do not mount standard binary directories of your system into the sandbox,
such as /bin and /usr/bin
Unless you know what you are doing. If your users can spawn other processes from within the process running the executable, they will be able to execute many other programs installed in your system, including shell programs, which means that you are probably giving your users more power than they should have.
3. Do not mount files and directories with sensitive information, e.g. /etc
If you do, you are potentially exposing sensitive data to your users, which may or may not be able to read them.
4. If you are not the only user of the Opt-Server, consider setting the
"mount-dependencies" property of your commands
to "FILES" .
By default, the Opt-Server will mount into the sandbox all the direct parents of the executable's
shared library dependencies. This makes the setup of commands more convenient, because there is a good
chance that standard library paths of your system (e.g.
The drawback to this default behavior is that maybe your executable depends on shared libraries that are within directories that you don't want to be readable — rather, only the specific shared library files should be readable.
You can see what files and directories are being mounted in the sandbox for a command using the
./opt-server --start --sandbox-info
Then call the command you want to inspect from the PIFOP IDE. You should see sandbox information printed out into
the terminal. Look for lines that say
If you see a path that you don't want to be readable, it is probably because of the behavior
of
5. If the program invoked by a command that you have configured has some kind of restrictive mode, consider enabling it.
For instance, the GAMS command line tool accepts an
A GAMS command can be configured in an Opt-Server with the