- User Since
- Sep 15 2020, 2:12 AM (18 w, 4 d)
Mon, Jan 11
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.
Wed, Dec 30
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.