Octory is a highly customizable product. It is natural to think about misuses, faults or to wonder how the application handles data. The following will give you a quick overview of Octory's main components.
Octory uses a plist configuration file to adapt its interface and its behavior. By editing it, you can deeply customize the application, like choosing its components to display, specify which apps should be monitored, and what MDM to use.
The app will look for a configuration file in two specific folders:
/Library/Managed Preferences/ for deploying your configuration via configuration profile is, by default, not writable except by the root user whereas the
/Library/Application Support/Octory folder is more flexible.
The configuration file has several sections. Each one holds a specific element of the application. To run a minimal version of Octory, you only need the
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 following permissions:
- The user owner is an admin and is the only one with the
- The group owner is "admin" or "wheel" and is the only one with the
- The user is an admin and the group owner is "admin" or "wheel" while the other owner has no
Starting with Octory
2.0.6, the permissions on the specified configuration file will be checked by the application to ensure only a user with admin privileges can edit it.
A Helper is a program to be handled with a LaunchDaemon and which will execute specific actions with root rights for Octory. You may have a use for it when executing a termination script with root rights or to execute certain Octory PRO actions.
Only Octory or other applications signed with the same certificate as the Helper can ask it to execute those actions, which ensures security.
As without it, the application can only read files in read only folders like
/Library/Application Support/Octory or
/Library/Managed Preferences, the files are securely uneditable unless with root privileges.
Octory's Helper is implemented following Apple guidelines in terms of security using XPC connections. The Helper will reject any connection from an application not signed with the same certificate as the one used for Octory.
For macOS 10.15 and lower, it is 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 this problem, it is possible to install a weak helper which will not check the connection. When doing so, it is your responsibility to remove the Helper once the onboarding is over.
The weak Helper has been removed from the download page but still available on demand. Please contact us directly if you need it.
If using the weak Helper, when Octory is uninstalled, the Helper should also be removed from the system as it would be useless and a potential threat.
More information and examples explaining how to install the Helper can be found here.
Octory retrieves several information about the system and the hardware to be used as placeholders. 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 during next launch.
While the application is running, it does not send anything to the network, except when the configuration uses a
SendRequest component. This can be verified by running a network analyser on the device like WireShark.
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.
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.
You can find Octory's session log at
/tmp/[username]-octory.log. It is dynamically filled with Octory logs to inform you about several things on the running session of the application. One of the best solutions is to use it with the Console app to watch Octory behavior.
A persistent log is written at
~/Library/Logs/Octory/octory.log with less info but useful for crash reports.
Octory's Helper log which shows the commands executed by the Helper as well as their outputs can be found at
Removing Helper's commands output from the log is possible by editing the Launch Daemon or running the following command:
sudo /usr/libexec/PlistBuddy -c "Delete StandardErrorPath" /Library/LaunchDaemons/com.amaris.octory.helper.plist