- User Since
- Sep 15 2020, 2:12 AM (45 w, 3 d)
Thu, Jul 22
Feb 3 2021
To round out the effort, i've added an optional patch to the series which provides granular AAA/RBAC from ring0 and can also deliver the W^X functionality for userspace along with those functions.
Feb 2 2021
Since 5.10 appears to be holding solid, and grsecurity is using 5.10 for their beta branch, i've completed the forward port of these core functions to the same kernel revision being used in the current branch (at the time of commit).
Whats the intent with Intel drivers there? If we want to pull in from Intel, i think we ought to do the same in-tree patch process to build and sign the modules at build-time (and enforce module signing validation to load at runtime).
Jan 23 2021
I've been refreshing the stack against current branch to keep testers building, and have added the FSGSBASE backport to 5.4 as a technical argument for keeping to a properly mature LTS even when users have a good case for needing newer functionality.
What is the plan of action for this effort, and is there a written policy on which kernels are selected and how they're selected for the OS? I can keep doing the rebase & push dance once a week or so, but is anyone on the VyOS team actually testing this stuff and has anyone upstream discussed the functional security benefits to users of GeoIP firewall filters or TARPIT/DELUDE/etc response actions separately from the system hardening functions inhere?
Jan 11 2021
systemd-container - easiest way to get containers rapidly into VyOS because all of the infrastructure (systemd) is already there.
We build our images with it, works fine.
You might want to take a look at the patches in T228 - its a 5.4 build with a bunch of C fixup, but using the Intel proprietary drivers for an in-tree build (permits signing of all modules at kernel build time).
We have this running on a host with a dual-port 740 (not doing all that much, some routing, NAT, ACL, and a couple of OpenVPN and IPSEC tunnels), and it seems to be fairly happy in that low intensity environment.
I can try to beat up on it and see how it fares, but probably worth a try.
Dec 30 2020
I've added the two binary defense components oustanding:
Dec 17 2020
So how are userspace packages for this sort of stuff handled? I assume we need to itemize out individual phabricator tickets?
Off the top of my head, relevant things to add to uspace would be:
- eoip binary
- eoip CLI wrapper
- Xtables userspace with GeoIP table data and updater script (we would need to figure out how to deal with rule placement for persistence)
- Xtables-related CLI for firewall matching on GeoIP, DNS, etc
- Xtables-related CLI for firewall actions to TARPIT or DELUDE
- UKSM userspace (or just wrappers for the sysfs interface in CLI)
- Hardened Malloc with system-wide LD_PRELOAD or maintain a vyos-specific libc package with it built-in
Dec 14 2020
Dec 7 2020
Important note on this PR - in order to build the GCC plugins which perform most of the self-protection work, the Docker container needs gcc-8-plugin-dev installed. Otherwise it builds, but silently downgrades the configs dropping RANDSTRUCT/STACKLEAK silently.
Pulled RSBAC out for now (issues with building the rest while its in there but disabled), validated builds with and without the plugins package for GCC8.
Added an inert patch (disabled in Kconfig) for https://www.rsbac.org/ on 5.4. This can be used to significantly harden the restrictions intended by the CLI to limit users to specifically defined roles, same goes for applications/containers.
If adding container support to VyOS is still on the roadmap, we're going to want to take extra care to enforce the boundaries between them and the host since real world use cases are pretty much guaranteed to leave old vulnerable containers running on long-running network appliances making for a variable and worsening attack surface over time.
This isn't quite as integrated and doesnt provide nearly the coverage as what you get with grsec+pax, but a rough approximation of "role-based FS restrictions and runtime hardening" is now in the pull request along with the other stuff which seemed pertinent for upstream.
Thank you sir. Worked through a clean build, updated patches, rebased, and pushed.
Nov 24 2020
Created a GitHub PR against 5.4.78 with the core functions listed above, ixbe and QAT in-tree as well as wireguard (avoids the convoluted module builds and permits LTO/CFI passes)
Sep 16 2020
Sep 15 2020
While i appreciate that you have an opinion of what's "best," i'm not re-summarizing 10+y of Linux out-of-tree history to spoon feed someone data they can, and should (like good engineers do), acquire on their own. Several of those patches are simply in-tree integrations for things currently built and packaged as kmods by VyOS on an LTS tree, the rest are well documented long running projects of their own which one must research and review the source code for anyway to properly understand their function and benefit.