A word about security

As Octory is highly customisable, it is natural to think about misuses or faults. Or to wonder how the application handles data.


Configuration file

Octory should run with the current logged in user privileges. It is strongly not recommended to run it as root. This is why a privileged Helper is provided for Octory features which require root privileges, like storing the MDM API credentials in the keychain, or executing a script with root rights.
The implementation of this Helper provides a secure way to execute commands with root privileges. That said, as the application is customisable, it is required to ensure that only the root user can customise it. This is why the application will use a configuration file only when it has the right permissions:

Also, the app will retrieve a configuration in two specific folders: /Library/Managed Preferences/ and /Library/Application Support/Octory. The folder Managed Preferences is by default not writable except by the root user. Whereas the folder /Library/Application Support/Octory is more flexible.


The Helper is implemented following Apple guidelines in terms of security using XPC connections. Also, the Helper will reject any connection from an application not signed with the same certificate as the one used for Octory.
It's possible that you encounter a problem with the Helper when executing actions or running the termination script in specific use cases like prestage enrolments. When such problems arise, the logs print a "Couldn't get 'secCode' message.
To prevent the problem, it's possible to install the weak helper which will not check the connection. When doing so, it's your responsibility to remove the Helper once the onboarding is over. To use the weak helper, download the octo-helper-weak.pkg from the downloads page.

Neverless, if Octory is uninstalled, the Helper should also be removed from the system, as it would be useless and a potential threat that can be avoided.
More informations and examples explaining how to install the Helper can be found here.


Octory tries to retrieve information about the system and hardware for it to be used as placeholders, as mentioned on the documentation. This information is internal to Octory, and only available while Octory is running. When the application is terminated, those information are not stored, and the application has to retrieve them again.

Moreover, while the application is running, it does not send anything to the network, except when the admin-user specified a SendRequest. This can be verified by running a network analyser on the device like WireShark.

API request

As mentioned, Octory can send request to an API if the admin-user specifies it. Thus, it has to securely store the credentials to authenticate to the API. To do so, the credentials are once passed as arguments when launching Octory in the command line. Then, those credentials are stored in the system keychain through the privileged Helper. This way, only the root user can access to them, or an application with root privileges, but not the end-user.

It is then up to the admin-user to make sure that no other application will read those credentials if not allowed. Also, the admin-user should think to clear the command line history after having launched Octory with the credentials arguments. This is to prevent those credentials to be retrieved them if the system was hacked and the hacker gained root privileges.


Octory can read any folder which can be read by the end-user themselves and is not sandboxed. This a trade-off Amaris makes to avoid the admin-user to authorise every read operation since Catalina.

Log files

Octory will read the MDM or system log files to offer monitoring features. Most often, those log files can be read by any user, and do not contain sensible information. Moreover, the session log file is only stored in the /tmp folder, whereas the log stored in at /Library/Logs/Octory/octory.log contains only information useful for crashes and other similar problems.