Change Details

Our company maintains several trees of hardened Linux kernels with extended functionality for scheduling, networking, and storage (we pretty much have our own Arch distro). While our primary efforts focus on development atop Grsecurity kernels, we maintain a parallel tree using the GrapheneOS kernel patches (linux-hardened) for distribution to clients who do not acquire Grsecurity patches from Open Source Security Inc. During out internal work on VyOS we've incorporated all of the out-of-tree kmods and patches directly into the kernel source - ixgbe, qat, stackable FS changes, etc. We have extracted these efforts along with applicable other patches to use in VyOS which provide: 1. xtables-addons in-tree: iptables modules for geoip, tarpit, etc 2. PF_RING in-tree: this can underpin NIDS traffic collection and other direct-access network functions 3. LVS patches: http://ja.ssi.bg/ 4. IPoE in-tree: VyOS patch adapted for 5.4 tree 5: VLANmon in-tree: VyOS patch adapted for 5.4 tree 6: WireGuard official in-tree backport 7: AUFS5 to permit complex overlays without the efficiency issues of overlayfs 8: EoIP protocol driver in-tree: support MikroTik L2 tunneling protocol 9: UKSM in-tree for userspace memory dedup: this will be very handy once Dockers are being run in VyOS (we use systemd-nspawn today to do things like run Duo's authproxy, works great) 10: Inotify VyOS patch adapted for 5.4 11: RT6 link filter VyOS patch adapted for 5.4 12: Linux-Hardened: ASLR patches, some community backports from grsec, reduces privileged access vectors, hardens and fixes type issue on certain structures and data types, etc. Basically makes the OS-tier harder to attack, its no grsec, but its IS better than upstream. Can also theoreticaly work with LTO+CFI with Clang, though we use GCC in-house to take advantage of RANDSTRUCT and such (custom kernels which aren't distributed gain decent standoff from this, distro kernels benefit too, though less). 13: If desired, we can also push up our linux-hardened + RSBAC patch to provide full-fledged RBAC implementation on vanilla/hardened kernels. Once this is done, we will upstream implementation of Hardened Malloc from https://github.com/GrapheneOS/hardened_malloc to help tighten up userspace memory defenses (we run it on our images, for a while now, no issues there). None of this will make your system impervious, but memory corruption attacks will be harder (a lot harder remotely), same for privesc, and actual network defensive capabilities using XTables (geoip firewall rules are handy). We tend to track LTS' so can support this work ongoing with minimal overhead if VyOS sticks to those kernels, or if we have to support yet another tree, we can work with the VyOS team to transfer knowledge and share maintenance costs for the effort.

Our company maintains several trees of hardened Linux kernels with extended functionality for scheduling, networking, and storage (we pretty much have our own Arch distro). While our primary efforts focus on development atop Grsecurity kernels, we maintain a parallel tree using the GrapheneOS kernel patches (linux-hardened) for distribution to clients who do not acquire Grsecurity patches from Open Source Security Inc. During our internal work on VyOS we've incorporated all of the out-of-tree kmods and patches directly into the kernel source - ixgbe, qat, stackable FS changes, etc. We have extracted these efforts along with applicable other patches to use in VyOS which provide: 1. xtables-addons in-tree: iptables modules for geoip, tarpit, etc 2. PF_RING in-tree: this can underpin NIDS traffic collection and other direct-access network functions 3. LVS patches: http://ja.ssi.bg/ 4. IPoE in-tree: VyOS patch adapted for 5.4 tree 5: VLANmon in-tree: VyOS patch adapted for 5.4 tree 6: WireGuard official in-tree backport 7: AUFS5 to permit complex overlays without the efficiency issues of overlayfs 8: EoIP protocol driver in-tree: support MikroTik L2 tunneling protocol 9: UKSM in-tree for userspace memory dedup: this will be very handy once Dockers are being run in VyOS (we use systemd-nspawn today to do things like run Duo's authproxy, works great) 10: Inotify VyOS patch adapted for 5.4 11: RT6 link filter VyOS patch adapted for 5.4 12: Linux-Hardened: ASLR patches, some community backports from grsec, reduces privileged access vectors, hardens and fixes type issue on certain structures and data types, etc. Basically makes the OS-tier harder to attack, its no grsec, but its IS better than upstream. Can also theoreticaly work with LTO+CFI with Clang, though we use GCC in-house to take advantage of RANDSTRUCT and such (custom kernels which aren't distributed gain decent standoff from this, distro kernels benefit too, though less). 13: If desired, we can also push up our linux-hardened + RSBAC patch to provide full-fledged RBAC implementation on vanilla/hardened kernels. Once this is done, we will upstream implementation of Hardened Malloc from https://github.com/GrapheneOS/hardened_malloc to help tighten up userspace memory defenses (we run it on our images, for a while now, no issues there). None of this will make your system impervious, but memory corruption attacks will be harder (a lot harder remotely), same for privesc, and actual network defensive capabilities using XTables (geoip firewall rules are handy). We tend to track LTS' so can support this work ongoing with minimal overhead if VyOS sticks to those kernels, or if we have to support yet another tree, we can work with the VyOS team to transfer knowledge and share maintenance costs for the effort.

Our company maintains several trees of hardened Linux kernels with extended functionality for scheduling, networking, and storage (we pretty much have our own Arch distro). While our primary efforts focus on development atop Grsecurity kernels, we maintain a parallel tree using the GrapheneOS kernel patches (linux-hardened) for distribution to clients who do not acquire Grsecurity patches from Open Source Security Inc. During outr internal work on VyOS we've incorporated all of the out-of-tree kmods and patches directly into the kernel source - ixgbe, qat, stackable FS changes, etc. We have extracted these efforts along with applicable other patches to use in VyOS which provide: 1. xtables-addons in-tree: iptables modules for geoip, tarpit, etc 2. PF_RING in-tree: this can underpin NIDS traffic collection and other direct-access network functions 3. LVS patches: http://ja.ssi.bg/ 4. IPoE in-tree: VyOS patch adapted for 5.4 tree 5: VLANmon in-tree: VyOS patch adapted for 5.4 tree 6: WireGuard official in-tree backport 7: AUFS5 to permit complex overlays without the efficiency issues of overlayfs 8: EoIP protocol driver in-tree: support MikroTik L2 tunneling protocol 9: UKSM in-tree for userspace memory dedup: this will be very handy once Dockers are being run in VyOS (we use systemd-nspawn today to do things like run Duo's authproxy, works great) 10: Inotify VyOS patch adapted for 5.4 11: RT6 link filter VyOS patch adapted for 5.4 12: Linux-Hardened: ASLR patches, some community backports from grsec, reduces privileged access vectors, hardens and fixes type issue on certain structures and data types, etc. Basically makes the OS-tier harder to attack, its no grsec, but its IS better than upstream. Can also theoreticaly work with LTO+CFI with Clang, though we use GCC in-house to take advantage of RANDSTRUCT and such (custom kernels which aren't distributed gain decent standoff from this, distro kernels benefit too, though less). 13: If desired, we can also push up our linux-hardened + RSBAC patch to provide full-fledged RBAC implementation on vanilla/hardened kernels. Once this is done, we will upstream implementation of Hardened Malloc from https://github.com/GrapheneOS/hardened_malloc to help tighten up userspace memory defenses (we run it on our images, for a while now, no issues there). None of this will make your system impervious, but memory corruption attacks will be harder (a lot harder remotely), same for privesc, and actual network defensive capabilities using XTables (geoip firewall rules are handy). We tend to track LTS' so can support this work ongoing with minimal overhead if VyOS sticks to those kernels, or if we have to support yet another tree, we can work with the VyOS team to transfer knowledge and share maintenance costs for the effort.