Threat model

A threat model outlines the security assumptions, potential risks, and defense strategies of a system. This document describes how Ocelot-Cloud mitigates threats to protect its digital infrastructure.

Security Measures

Cryptography

We only use modern, well-tested cryptographic algorithms. Administrators can generate Let’s Encrypt–signed certificates or provide their own certificates to secure HTTPS endpoints.

Container Isolation

Every app runs in its own Docker container with no shared volumes, networks, or Docker socket access, and with restricted Linux capabilities.

Defensive Coding

  • Strict input validation blocks SQL injection, XSS, RCE, and similar attacks.
  • Protection against CSRF attacks is built into the security framework.
  • App releases are zip files. When an app is uploaded to the App Store or downloaded by Ocelot-Cloud, it is checked for zip bombs and its consistency is validated to ensure that apps are always executed inside a sandbox.
  • Cookies are hashed, and passwords are salted and hashed. This means that even if a hacker gains access to the database, they won’t be able to read them in plain text. Therefore, cookies and strong passwords are effectively impossible to crack.

Secure Supply Chain

  • Static code analysis tools run frequently.
  • Automated update tools ensure releases use the latest libraries and Docker images.

Access Control

  • All endpoints enforce authentication and role-based authorization.
  • Administrators can define access policies for apps, restricting access to specific users.

Backups and Updates

  • Ocelot-Cloud automatically updates apps and creates backups.
  • Ocelot allows backups to be stored on remote servers using end-to-end encryption. This enables disaster recovery in case of hardware failure or data loss, but must be set up by the administrator.

Limitations and Assumptions

The following areas remain under the administrator’s control and are out of scope for Ocelot-Cloud’s built-in safeguards.

Infrastructure

  • When an administrator hosts Ocelot-Cloud on his own hardware, he is responsible for the physical security of the servers and networks.
  • Host OS and Docker Engine updates must be maintained by the administrator to ensure security. We recommend using a simple, automatically updating system like Ubuntu, along with a cron job to reboot regularly.
  • OS-level network security such as firewall configuration must be enforced by the administrator to protect the deployment.

Apps and Data

  • App Store content is not moderated, except for official apps. Third-party apps may contain malicious code, so we recommend that administrators only use trusted third-party sources or evaluate third-party apps before installation.
  • App updates depend on each app’s maintainer. Outdated apps may introduce vulnerabilities.
  • Ocelot-Cloud is not responsible for security vulnerabilities within installed apps. Responsibility for application-level security lies entirely with the respective project developers.

Miscellaneous

  • The owner of the Ocelot-Cloud installation is responsible for legal and regulatory compliance, such as privacy laws, although Ocelot-Cloud provides tools to help reduce the effort involved.
  • Ocelot-Cloud comes with a default self-signed certificate. Although this might be suitable for trusted LAN environments, it is vulnerable to man-in-the-middle (MITM) attacks. To ensure security, administrators must upload or generate a trusted certificate and keep it up to date.