Help Resources PIFOP Usage Getting Started Running a Solver Provisioned Optimization Server Collaboration and Sharing Options Supported Languages and Files Working with Google Sheets Markdown + LaTeX Project Answer Project Collections Subscription Keys List of Examples Hosting an Optimization Server Introduction to Optimization Server Hosting Hosting an Opt-Server Configure Commands Basic Command Configurations Security Best Practices Manage Users List of Configuration Options AMPL Basics Program Structure Model Entities Set Expressions Indexing Expressions Data Assignment Basic Commands More AMPL References Attributes of Sets, Parameters and Variables Printing Commands and Options

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. /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 — 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 --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 and necessary for the sandbox to work.

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.

A GAMS command can be configured in an Opt-Server with the "append-options" property set to "execMode=4", which makes that this option is appended to every command line calling GAMS.