Orion Security

“Security through obscurity is not much security at all.”

Popular paraphasing of American locksmith Alfred Charles Hobbs in 1851, who easily picked the Crystal Palace locks during a London exhibition that year. We fully agree, which is why our blueprints for our Oracle Cloud Infrastructure (OCI) automation engine are available on GitHub.

Orion Infrastructure Security

FIPS 140-3 compliant w/MFA triple-encryption for reverse-port-forwarded services (HTTPS/SSH/IPsec). Belt, suspenders, and stirrups!

RBAC model, peppered with orthrus OTP/TOTP challenges

All infrastucture account login access requires providing Multi-Factor Authentication credentials, including OCI accounts. There are no backdoors to this policy, by design.

All employee ssh access to corporate machines requires YubiKey PKI integration with either ECDSA-SHA-2-NISTP-256 authorization private keys stored in PKCS11 slots on the Yubikey, or direct Smart Card integration with ED25519-sk Pkeys.

No fixed passwords stored on disks. This limits headless automation of sudo / RBAC usage, for good reason. However, we have tooling to eliminate the toil of responding to prompts of various kinds.

Sandboxed execution for builds and CGI scripts

We deploy “shared-nothing” zone builds, defaulting to zero network availability. This means the only things a customer build can access or modify are their own assets, not those any other customer, or any other system paths on the zone itself (besides /tmp. Furthermore, only Business and Enterprise customers have internet access during their builds, because they are using their own unique Solaris zones that can be tailored exactly to their build requirements.

Ditto for CGI scripts, which are fully locked down in terms of write access to anything other than /tmp.

End to end encryption

• OpenSSL v4+ TLS 1.3 (+FS) AES(256) SHA(256) for HTTPS FIPS 140-3 connections

• OpenSSH v10+ ED25519 FIPS 140-3 with Post-Quantum KexAlgorithm / NIST compliant keys for cross-host lo reverse-port-forwarding

• IPsec/IKEv2/PFS AES(256) FIPS 140-2 for cross-regional VPN

• AES(256) for ZFS encryption

Zero Trust aspects

The basic premise of zero trust architecture is to avoid designing your network security around the physiology of clam: hard on the outside, but soft and loose once you are in. So we don’t do that; every meaningful privileged network port inside the various Point of Presence (POP) LANs is only exposed to the bare-metal machine’s loopback device interface lo0, and is only meaningful in the context of a (reverse) port forwarded SSH connection to it.

We use TCP proxies, not HTTP proxies, and no MSA backends, so the only host that sees your unencrypted TLS web traffic is the host that decrypts it. Same rules apply to Subversion traffic — only direct, end-to-end TLS encrypted traffic to the service endpoint sees your unencrypted data on the wire.

Good luck with the MSA layers and layers of private data exposure with other vendors. The enemy of “nonfunctional engineering” is complexity. It is a lot easier to provide meaningful security promises when your product is a federated monolith instead of a massive MSA minefield, which is another contrarian differentiator between Orion and its field of competitors.

This infra is fully automated once a region is brought online, but that’s all we can share publicly about the architecture (balancing Hobbsian transparency with the military mantra “loose lips sink ships” is more art than science). Rest assured — beyond breaking the antispoofing lo0 protection within Solaris 11’s (BSD) packet filter itself, there is no meaningful means of gaining access to these services, even for customer accounts.

Even if the master OCI control account is compromised, the confidentiality and integrity of all customer assets remains inviolate. All a black-hat can do is make a mess with customer website availability. In particular, they cannot access the Subversion service data records. We can reconstruct the entire OCI infrastructure from scratch in 48-72 hours once the bad apple’s OCI access has been terminated.

Logging, Monitoring, and Auditing

We encourage Enterprise customers to create a Splunk account, and we will deliver near-real-time weblogs to your account from every global POP you require. Error logs for your server-side CGI scripting are also made available to Splunk.

We monitor service availability from all our OCI POPs world-wide, and trigger HA (Availability Domain), or regional, failover events if a server outage lasts for more than 30 seconds.

ACL Auditing can be performed by simply building a website’s Subversion HEAD using the Apache Licensed Orion SSG script and examining the resulting build to the www/.acl file in your checkout directory, at any time you wish. Normally the build process will take less than 10-15 seconds on modern hardware.

Subversion Server-Side Commit Hooks are also customizable to your oversight concerns. From a simple commit mailer to secured access to our svnpubsub daemon, there are any number of custom configurations available.

Orion Application Security

Public SSR is a smell

Separation of Concerns and Engineering Tradeoffs

In a nutshell, the way every other wiki platform works is as an SQL CRUD app that makes it quick and easy to modify content, for which the results have to be reconstructed in real-time (or from a webpage cache) every time someone needs to view that content online.

In (noSQL) Orion, we take editing and rendering as two separate concerns that should be handled by two independent software stacks; where much more process, design, validation, and dependency management is invested in the editing interface. This is so that we can limit the software on the rendering stack to be a barebones SSI-enabled Apache file server with bog-standard web authentication and access controls involved, and optimistically we expect that the content is viewed an order of magnitude more often than it is edited.

Consequently, the editing experience happens on an impossible-to-access-without-a-valid-login independent web stack, is a little less quick once the changes are uploaded, and is a lot less dirty; because we validate and build the modified content, along with the entire corpus of dependent pages, at edit-time, not at render time. The build happens in a separately hardened, sandboxed Solaris Zone. The build logs are published to the editing session in real time, and saved in version control for posterity and business accountability.

In reality, the cost is a few seconds more of exposure to the build’s technical machinery and static file deployment process before being able to view committed, published changes on the live production website.

And the benefit? You will never see your live website get hacked again through zero-day or unpatched vulnerabilities in the rendering webserver’s software stack. Moreover, the editing site is invulnerable to anonymous hacking efforts, so you are in a much better security-architectural position with us than with any other wiki vendor on Earth, regardless of the additional protections implemented in the remainder of this document.

Neat trick, ain’t it?

But it critically hinges on that tradeoff being viable to the editor experience. And without application of our patent-pending Smart Content Dependency Management™ framework, may not be worth the cost for many businesses.

ACL Management

Orion’s security model is centrally managed by the settings contained in @path::acl as constucted in lib/path.pm. Offshoot server configuration files are dynamically generated on every built change.

If you understand the POSIX filesystem security model, you will be right at home with Orion’s mod_dav_svn authorization model and the Apache HTTPd webserver’s .htaccess controls, automatically generated from your website’s lib/acl.yml YAML configuration.

OpenIDC SSO Security

All OpenID session cookies are HttpOnly and Secure flagged, so Javascript session stealing attempts are effectively neutralized by the Orion Online Editor.

All cookie credential storage is additionally AES-256 encrypted beneath an HMAC SHA-1 hash.

Bcrypt for Subversion passwords

Adjustable number of rounds (currently defaults to 5). Here’s a blog entry that explains the relevance.

Tainted Data Protections

All of our Perl runtimes have mandatory taint checks enabled with the -T flag; a powerful, uniquely Perl guard against Remote Shell Exploits.

Wiki Issues

Wiki security involves several factors:

1. UI/API Security

2. Middleware/Backend Security

3. Template Traversal Protections

4. Template String Literal Security

5. Search Engine ACL compatibility

We delve into these issues as they relate to Orion below.

Online Editor

The online editor supports a JSON UI by simply setting your user-agent’s Accept header to prefer the application/json MIME-type, so the security controls are the same for both the UI and API.

There is no administrative UI/API outside of direct Subversion access. Instead, we offer certain data views in the free search engine that may be used to construct access-controlled dashboards within the hosted website.

Otherwise, each website is goverend by the configuation files in the website’s base lib/ directory of the source materials in Subversion.

Subversion ACLs govern server-side working copy read access

Each working-copy resource available through the UI is cross-checked against your Subversion ACLs prior to presenting them to the user. In this way we ensure read-access to unauthorized resources is prevented for the assets under version control (aka everything).

Commit access is directly controlled with Subversion ACLs

Nothing can be built and subsequently viewed over the network without a corresponding authorized Subversion commit. The main issue here is in controlling what information is available to a wiki page author’s committed and built edits.

If you allow Template preprocessing in the markdown source pages, you need to be aware of how template arguments make the contents of other files in the tree available as variables to the source of the edited page.

Often times, if configured to do so, the edited page can declare its own dependency files in the headers of the page, which is also something to think about as you weigh feature-sets against security-controls in your Wiki’s Information Architecture. Regardless of your stance, we secure your site by default — including content dependencies and ssi includes.

While we can offer guidance and support to match your needs, it’s really up to you to decide how to balance the scales for your organization’s managed assets in an Orion-backed wiki.

See the below section on Dependency/ACL Injection Controls for more details, and checkout this live example of how easy ACL’s can be centrally configured in lib/acl.yml:

- path: content
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: content/orion
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: lib
  rules:
    "@svnadmin": rw
    "@devops": rw

- path: lib/acl.yaml
  rules:
    "@svnadmin": rw
    "@security": rw

- path: templates
  rules:
    "@svnadmin": rw
    "@frontend": rw

- path: cgi-bin/search.pl
  rules:
    "@svnadmin": rw
    "*":

Content Authors can configure page restrictions in the page’s headers:

Title: Orion Security
Dependencies: *.md.en api/index.md.en
ACL: @staff=rw, *=r
Keywords: security,infosec,appsec,ipsec,devsecops,it,acl,svnauthz,zerotrust

As a side note, protected resources cannot be copied into a branch by unauthorized personnel, even without placing any additional ACL controls on branch creation and modification. In other words, the system will support branch experimentation without any additional controls on your part to ensure protected assets remain protected throughout each branch’s natural lifecycle.

Build System ACLs?

The build system is all-seeing and all-knowing, but we can ensure that your built, protected assets are only visible to the teams you manage and control in the Subversion ACLs.

The build system will reveal the list of file names it built through the browser IDE upon a commit, but that list is only based on an user’s read-access to the resources dependent on the user’s add, update, or delete content actions in the commit.

Template Traversal Controls

See sanitize_relative_path:

sub sanitize_relative_path {
  for (@_ ? @_ : $_) {
    s#^[\\/]+##g;
    s/^\w+://g; #Windows GRR
    s#([\\/])+#$1#g;
    s#/\./#/#g;
    1 while s#[\\/][^\\/]+[\\/]\.\.[\\/]#/#;
    s#^(?:\.\.?[\\/])+##;
  }
}

This code enforces the rules which follow below in this section.

include and extends tags

All target files are in a subfolder of the /templates/ folder, and must be referenced as absolute paths rooted at that folder.

ssi tag

All target files are in a subfolder of the /content/ folder, and must be referenced as absolute paths rooted at that folder.

If the target path is not configured in @path::patterns with a matching setting that allows the target path in question to either be archived or categorized, or the last changed author of the source file is simply not authorized to view the target path, the ssi operation will fail.

This is because ssi support is a pre-requisite for those feature-sets, to preserve your site’s target permalinks.

Filter Security Involving Regular Expressions Passed as String Literals

Dotiac::DTL internally urlencodes all string literals before exposing them to eval for security reasons. It then leaves them encoded when passed as filter arguments, which is frustrating when working with PCRE string literals.

In that situation, our fork of Dotiac::DTL urldecodes the string and does a sanity check in a Safe::reval sandbox before exposing them to perl‘s regex engine. The upside is that the string literals you type into a supported filter argument will be exposed verbatim to perl — you do not need to double-escape your backslashes!

Dependency/ACL Injection Controls

Controlled by lib/path.pm imports.

lib/{path,view}.pm Subversion ACLs

It’s wise to control write access to these resources, by limiting them to people both competent in the codebase and authorized to implement security controls for the entire set of assets under version control (aka everything).

It is also a good idea to include the @svnadmin group amongst those with read-write access, but it’s not strictly necessary even if you need us to manually reset your Subversion ACLs.

Dynamically Generated Rules via @path::acl

The build system takes note of your lib/path.pm imports of either (or both) of seed_file_deps() and seed_file_acl(), and carry that choice forward in its internal processing of Subversion commit changes that give rise to an incremental build.

Controlled Content Migration Tracking

When you expose the full version control history to your users, care must be taken to preserve authorization controls on the original location of the controlled material.

Otherwise the material could be inadvertently exposed to a historical researcher without the requisite authorizations.

The Orion CMS’s move/delete tracking logic handles this seamlessly.

Custom Controls on seed_file_deps() and seed_file_acl() usage in lib/path.pm

Beyond the import of these symbols to lib/path.pm, there is also a choice in how, and to which files you wish to apply them to, during a walk_content_tree () code block execution. After all, it’s not just a config file, but a codebase, with all the Turing complete features of Perl we’ve come to know and appreciate!

Built Website .htaccess files, and Subversion authorization files, are synchronized with @path::acl instantly upon commit

Automatic ACL protection for ephemeral branch builds. Zero additional configuration required.

PCRE Search Engine Builtin Controls

Same situation as the general-purpose UI: it cross-checks against the Subversion server from the UI.

On the live site, the search engine will do the exact same when you enable markdown (source tree) searches. Otherwise, it will run httpd subrequests to your live site to test whether the user is authorized to access that live file (assuming you have password-protected your search engine so it has user data to work with).

Content Security Policies

• Analytics Restrictions

Google, X, and/or LinkedIn.

• Data Restrictions

Data must be delivered from our servers.

• Content Restrictions

Content must be delivered from our servers.

• Code Restrictions

Javascript Code must be delivered from our servers.

• Style Restrictions

CSS must be delivered from our servers.

• Plugin Restrictions

Currently PDF’s only.

Cross-Origin Resource Sharing

• All users with an account can consume UI/APIs from elsewhere using their login credentials.

• Business and Enterprise customers can treat Orion as a Headless CMS if they want to build their own UI from the JSON Subversion Porcelain or JSON Search APIs.

Third-Party Dependencies

Remarkably brief and time-tested dependencies; the major components of which are covered on the Orion Technology page.

Full Software Bill of Materials (SBOM) Available upon Request

Contact Us for more details.