Application Profiles are used to apply specific settings to applications. Whenever an application first becomes active on the network, the Portmaster creates and loads the corresponding Profile that should be applied.
There are four profile types. When making decisions, the Portmaster merges these profiles together and draws preferences from this set. The following list is displayed in the correct precedence.
The “default profile” is the combination of the Global and the Fallback Profile. The difference is that the Global Profile will overrule the Stamp Profile while the Fallback Profile may be overridden by Stamp Profile settings.
The User Profile is the application’s own profile. It overrides all other profiles.
The Global Profile is shared among all applications and overrides the community supplied Stamp Profile.
These Profiles are built and managed by the Stamp Community. These profiles are especially helpful if you are not very adept technically and generally give you good baseline of a Profile. (coming soon)
This profile is also shared among all applications and holds sensible defaults for applications that have no other more specific settings applied to it.
In addition to the global Security Level, you may also define a minimum Security Level for an application in it’s profile.
Flags allow you to quickly define basic behavior.
The Profile Mode defines how the Endpoint list below should be treated. Whitelist takes precedence before Prompt takes precedence before Blacklist.
Define the network scope for this application.
Define special behaviour.
You can block labels defined by Stamp. (coming soon)
If the Flags and Labels were not detailed enough for you, here you can really get down to it. An Endpoint is a single or a collection of Internet entities:
Any of these may also additionally and optionally specify an IP protocol and a port range.
There is a second list, called Service Endpoints that controls inbound connections.
This system is work in progress and is currently not part of the Portmaster. Please participate in discussion on our forum.
Sometimes a program path may not be the real entity that is executing code. The Framework settings provides a mean to identify the real actor behind a program. For example, when a python script is executed, the program path will be that of the python interpreter, but we actually want to match against the script that is executing, not the interpreter.
When a Profile with a Framework is evaluated, the executable path will be rewritten and the a new Profile will be searched for with this path.
Going down the process tree - eg. finding the actual script of an interpreter:
Going up the process tree, using the path of the parent process to match a profile: