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.
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:
- 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
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, add the
--weak flag when calling the install script.
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.
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. 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.