SunStar Orion Symbol Linear
Home » Orion   Edit Icon

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

flowchart TB classDef borderless stroke-width:0px classDef darkBlue fill:#00008B, color:#fff classDef brightBlue fill:#6082B6, color:#fff classDef gray fill:#62524F, color:#fff classDef gray2 fill:#4F625B, color:#fff subgraph vcs[ ] A1[[Fort Lauderdale, FL]] B1[Air-Gapped Version Control Server] end class vcs,A1 gray subgraph vpn-us-east[ ] A2[[Reston, VA]] B2[OCI Edge Servers] end class vpn-us-east,A2 darkBlue subgraph vpn-us-west[ ] A3[[Phoenix, AZ]] B3[OCI Edge Servers] end class vpn-us-west,A3 darkBlue subgraph vpn-de-central[ ] A4[[Frankfurt, Germany]] B4[OCI Edge Servers] end class vpn-de-central,A4 darkBlue subgraph vpn-bz-west[ ] A5[[São Paolo, Brazil]] B5[OCI Edge Servers] end class vpn-bz-west,A5 darkBlue subgraph vpn-au-west[ ] A6[[Sydney, Australia]] B6[OCI Edge Servers] end class vpn-au-west,A6 darkBlue subgraph vpn-ap-west[ ] A7[[Hyderabad, India]] B7[OCI Edge Servers] end class vpn-ap-west,A7 darkBlue subgraph vpn-ap-east[ ] A8[[Seoul, South Korea]] B8[OCI Edge Servers] end class vpn-ap-east,A8 darkBlue class A1,A2,A3,A4,A5,A6,A7,A8 borderless vcs==vpn==>A2==ssh/vpn==>B2 vcs==vpn==>A3==ssh/vpn==>B3 vcs==vpn==>A4==ssh/vpn==>B4 vcs==vpn==>A5==ssh/vpn==>B5 vcs==vpn==>A6==ssh/vpn==>B6 vcs==vpn==>A7==ssh/vpn==>B7 vcs==vpn==>A8==ssh/vpn==>B8

 

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

 

Passwordless RBAC model, peppered with orthrus otp-sha1 sudo challenges

No fixed passwords stored on servers. 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

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.

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

digraph { "@path::acl" -> "authz-svn.conf" [label="svn"]; "@path::acl" -> "/**/.htaccess" [label="httpd"]; };

 

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 committed change.

OpenIDC SSO Security

Session Cookies are HttpOnly and Secure flagged, so Javascript session stealing attempts are effectively neutralized by the Orion Online Editor.

Bcrypt for Subversion passwords

Adjustable number of rounds (currently defaults to 5).

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. 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.

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 resourcces 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 availaible 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 something to think as you weigh feature-sets against security-controls in your Wiki’s Information Architecture.

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 enterprise 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:
    "@marketing": rw
    "@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:
    "*":

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

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, the ssi operation will fail.

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

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.

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 and Subversion ACL’s synchronized with @path::acl instantly upon commit

Automatic 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

Google and/or LinkedIn.

Data must be delivered from our servers.

Content must be delivered from our servers.

Javascript Code must be delivered from our servers.

CSS must be delivered from our servers.

Currently PDF’s only.

Cross-Origin Resource Sharing

Third-Party Dependencies

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

Software Bill of Materials (SBOM) Available upon Request

Contact Us for more details.

Index