Security
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.
Configuration file
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//Library/Application Support/Octory
The /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 Slides and Window groups.
Permissions
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
writepermission.
Ex:-rw-r--r-- - The group owner is "admin" or "wheel" and is the only one with the
writepermission.
Ex:-r--rw-r-- - The user is an admin and the group owner is "admin" or "wheel" while the other owner has no
writepermission.
Ex:-rw-rw-r--
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.
Helper
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.
Data
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.
User inputs
The values entered by the end user are written to the input variables file described in the Input configuration.
Since Octory 3.1.0, the values entered in a SecureText input are excluded from that file, so a password typed by the end user is no longer left in plain text on disk. They remain usable as variables inside the configuration while the application runs, and are censored in the logs.
Set SavesSensitiveInputs to true to restore the previous behaviour when a workflow of yours needs to read those values back. Anything running as the end user can read that file, so only do it when you have to, and remove the file once it has been consumed.
Messages
Any process running on the device can ask a running Octory to display a message, by sending a distributed notification, which is what the octo-notifier message command does.
A message can carry buttons, and a button can carry a shell command that runs as the logged-in user when the end user clicks it. Nothing runs without that click, and a message can never grant more privileges than the user already has, but it does mean a message shown by Octory is not a proof that your own tooling sent it. This is the same trust model as other macOS notification tools.
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 if the system was hacked and the hacker gained root privileges.
Files
Octory can read any folder which can be read by the end-user themselves and is not sandboxed. This a trade-off we make 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 sensitive 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 /tmp/octoryHelper.log.
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