Secure Envoy profile
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 437
Description
This issue continues from https://github.com/envoyproxy/envoy/issues/5348 and tracks the security specific concerns in a "secure Envoy" build. Ideas that we have heard about so far include:
* Conservative defaults for all buffer sizes and timeouts in the configuration.
* A `SECURITY_ASSERT` macro that might promote some extant `ASSERT` to `RELEASE_ASSERT`.
* Additional data structure and data plane payload integrity checks.
* Restricting allowed extensions to those tagged as valid for untrusted downstream/upstreams (see https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/threat_model#core-and-extensions)
* Build with Scudo allocator (https://github.com/envoyproxy/envoy/issues/9365)
* `-fstack-protector-all`
* `-fstack-clash-protection`
* https://clang.llvm.org/docs/ControlFlowIntegrity.html
* Anything else in https://wiki.debian.org/Hardening
* Enabling `ABSL_HARDENING_ASSERT`
Please propose others.
Contributor guide
Assessment
This issue has not been assessed yet.