Security Best Practices


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, regardless of how many people they are sharing it with.

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. Therefore, this list of best practices is not to make your Opt-server configuration safe, but to make it safer.

1. If you create a command to run a shell program, such as bash, make sure that you are not mounting sensitive executables and files.

Unless you know what you are doing.

2. Do not mount standard binary directories of your system as a whole into the sandbox, such as /bin and /usr/bin

Unless you know what you are doing. It is fine to mount a selection of safe executables within standard binary directoreis, but when you mount all of them, 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 can make the setup of commands simpler, because there is a chance that standard library paths of your system (e.g. /lib and /lib64) will be mounted in the sandbox whatever the command's executable is. Therefore, you will not have to manually mount any other paths. Even if the executable calls other executables, things will just work.

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 in its entirety, but only the specific shared library files needed by your executables.

You can see what files and directories are being mounted in the sandbox for a command using the --sandbox-info Opt-Server flag. After setting up a new command, run the Opt-Server with:

./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 Mount: '/some/path' .... These paths will be readable from within the sandbox.

The sandbox will always mount the /proc virtual file system. That's normal behavior and necessary for the sandbox to work. The mounted /proc only keeps track of processes spawned within the sandbox.

If you see a path that you don't want to be readable, it is probably because of the behavior of "mount-dependencies", which is "DIRECTORIES" by default. Change it to "FILES" so that only the shared library dependency files are mounted into the sandbox.

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 execMode option used to restrict what commands can be executed by the user — see the GAMS CLI reference on execMode — and AMPL has something similar with the R CLI option.

Use the prepend and append options command properties to configure default CLI flags.

Terms and Privacy Help Pricing About Blog Contact us Server Status Twitter LinkedIn