StackX: native hardening of the security model)
Following the flood of new vulnerabilities over the past few months, I decided to temporarily put my hacker hat back on and let StackX, ScalarX's managed infrastructure offering, benefit from it.
The idea: strengthen the security model natively without making day-to-day operations a nightmare for clients.
Origin of the approach
In the early 2000s, I designed the Manticore system for a US telecom operator: a set of security elements and measures intended to strengthen the security of the system (Solaris) so that it could be directly exposed. Some time later, I ported the solution to GNU/Linux, and that is actually how, one thing leading to another, I got into the managed infrastructure game.
Why StackX changes the game
The situation is different: Manticore was grafted onto a "hostile" and uncontrolled environment, onto a client's existing servers.
I do not have that constraint with StackX. I can build a defence in depth that fits the architecture, works in production and can always be verified locally, with no opaque dependency on an external platform.
I finished the bulk of the work last night. Right now, I am finishing a few additional tools for specific purposes.
Hardening: kernel layer
The hardening rests on several complementary layers.
On the kernel side: StackX natively blocks several families of modules that have no use on our managed platforms and that could be involved in exploitation primitives.
This does not include only the modules affected by Copy Fail or Dirty Frag, but also all of the families we have identified as the most at risk, several network protocols that are rarely necessary, as well as several legacy file systems that are not used with StackX.
Native mitigation, not a black box
This is neither a kernel recompilation, although I am still considering a dedicated kernel in the longer term, exclusively on ScalarCloud, nor a replacement for vendor patches. It is a native mitigation, readable, reversible, and adapted to the StackX context. The idea is also to be able to deploy new mitigations even faster, with a local ecosystem already designed for it.
This hardening does not replace vendor patches, updates or continuous monitoring. It adds a layer of attack-surface reduction, offensive friction and post-compromise limitation.
Sysctls and complementary controls
Other parameters have been hardened or restricted. The list is long, but examples include ptrace, BPF, kernel information leaks, dmesg, kptr, perf, protection against the classic hardlink, symlink and fifo attacks, the disabling of certain mechanisms that are dangerous or useless in the StackX context, or hardened management of user namespaces.
MAC layer: SELinux
For the MAC layer, I favoured SELinux over AppArmor, which is the Debian standard, as the main mandatory access-control layer. Client environments vary greatly, and some need to be more permissive than others. We therefore had to ensure compatibility by preparing the contexts, ports, paths and rules StackX needs. On installations where it is warranted, particularly for Enterprise clients, it is possible to obtain a real barrier fully adapted to the client's product.
StackX paths are typed: client web spaces, logs, scripts, data, secrets, non-standard ports, local services. The idea is not to slap a generic policy onto a specific architecture, but to have a security policy that actually understands how StackX works.
Mounts, services and local logic
We have also hardened mounts by default. This choice required adjustments to some services, for example OpenSearch, so as not to break the post-reboot startup of the JVM/JNA. That was precisely the intended objective: harden without undermining operations.
Application services such as Redis, OpenSearch, MariaDB, Memcached or PostgreSQL are configured to stay local by default: bind to loopback, no unnecessary network exposure despite the firewall layers already present, properly generated passwords, integration into the delivery files, monitoring, post-checks and maintenance scripts.
Monitoring and delegated administration
For monitoring, sxpostcheck, an internal tool, checks actual system states: SELinux configuration, active LSMs, blocked modules, kernel parameters, local services, listeners, ports, replications, backups, Redis, OpenSearch, PostgreSQL, VIP, DNS, cron, and several critical StackX states.
Local SMS monitoring has also been extended to track the new services, avoid false positives wherever possible and support ongoing improvements.
We also worked on delegated administration, a project we started some time ago for specific clients. Some StackX tools can be used via sudo by a dedicated non-root client administration account, but with much stricter restrictions: bounded commands, controlled paths, controlled imports/restores, refusal of operations that are too dangerous, and fewer ways to make tools read arbitrary files.
StackX philosophy
The idea is simple: delegate what can be delegated, without turning an administration wrapper into a privilege-escalation flaw.
Finally, everything stays local-first. StackX continues to favour readable Bash scripts, explicit configuration files, local logs, local checks, mechanisms auditable by a system administrator or an agent. No compulsory cloud dependency, no black box, no declarative security you cannot review.
This model increases the cost of exploiting a vulnerability, reduces the attack surface, limits certain post-compromise possibilities, and gives operators concrete tools to verify the real state of a machine.
StackX evolves while staying faithful to its philosophy: lean, robust, auditable infrastructure, designed for real servers, real clients, and real production constraints.
—
Christophe Casalegno (find all my social media at: all.bo)
Leave a comment
Add a comment