Page MenuHomeVyOS Platform

Hardening: initial hardening efforts
Closed, InvalidPublic


The goal is to procure a hardened networking OS, resilient to remote network attacks as well as progression of remote attacks into local exploitation scenarios. To this end, the following changes are considered:

  • Signed LKMs and monolithic kernels, to prevent trivial injection of arbitrary code in the kernel address space through the LKM subsystem (ex. rootkits).
  • Process and user isolation: users and processes should be isolated, deterring access to those objects and interfaces that are not needed for them to function properly. This includes procfs access, other OS filesystems for runtime information, etc.
  • The deployment of a MAC or RBAC framework and a policy to achieve the above, plus offer protection against unknown vulnerabilities in the bundled software by locking down the different applications and tools to the least-privilege primitives needed to operate, and nothing else.
  • Filesystem integrity: because VyOS for the most part could easily live off a permanently read-only root filesystem, we can also leverage file integrity checking to load a signed, trusted database of cryptographic hashes of files and executables on the system. Should these files change through means different than approved updates, we would be able to detect from the most trivial forms of local compromise to corrupted critical system files.
  • Kernel self-protection: many of the features above are completely exposed to being disabled, should the kernel be successfully targeted. Because of the importance of assuring integrity of the security frameworks, certain modifications will need to be applied to the kernel to deter successful exploitation of kernel-level vulnerabilities.
  • Improved ASLR/memory permissions. Running programs should benefit from increased ASLR effectiveness and prevention of dangerous memory protection primitives (ex. write-execute). Linux comes with ASLR, for example, but it needs to be tuned to explicitly increase the level of entropy per address, and it leaves certain areas out of scope. Compared to past solutions like PaX it does not reach the same level of effectiveness.

The advantages of VyOS vs most mainstream operating systems, including Debian itself, is that VyOS is a mostly static, non-changing set of executables, libraries and kernel images. It does not have a package manager because packages are not meant to be installed or removed. It is a highly tailored, purpose-built system for networking purposes. This allows us to implement, test and deploy hardening modifications with ease, compared to regular desktop systems. It allows us to know exactly what a trusted (as long as the build systems used are trustworthy and not compromised) image of the system contains and looks like, and detecting anything that deviates from that initial state.

At the moment the biggest showstopper is the lack of consistent documentation that, basically, tells a novice project member like me how to "go from an empty tree to a standalone built image ready to boot", while also documenting best practices or at least, where to find each component and what it is and how it operates.

As far as my involvement goes, this work is being supported by Subreption LLC and my personal appreciation of the project as an incredibly useful networking-oriented operating system.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close

Event Timeline

lh created this object in space S1 VyOS Public.
syncer triaged this task as Normal priority.Jul 20 2018, 12:39 PM
syncer changed the visibility from "Subscribers" to "Public (No Login Required)".
syncer added a project: VyOS 1.3 Equuleus.
syncer edited subscribers, added: Maintainers, Active contributors; removed: Sentrium.
syncer edited projects, added Invalid; removed VyOS 1.3 Equuleus, vyos-build, vyos-kernel, VyOS 2.0.x.
syncer added a subscriber: syncer.

seems to be abandoned