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, 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.
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
./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
Use the prepend and append options command properties to configure default CLI flags.