Securing software while maintaining usability
summary
Elasticsearch hardens runtime by adding a JVM-level Java Security Manager with per-plugin policy files, a native seccomp policy (about 500 lines of platform glue) to block unwanted syscalls, and bootstrap checks that refuse startup as root, enforce file-descriptor and thread limits, and detect unsafe JVM/GC versions. The security manager takes nine months of engineering to integrate but becomes always-on; plugins ship explicit settings so mis-typed configs are flagged and sensitive keys stay filtered, enabling pragmatic sandboxing without breaking normal operation.
AI-written summary · about
chapters (21)
- 0:00Start
- 0:36Today's goal
- 2:10Elasticsearch in 10 seconds
- 4:10Naming is hard
- 5:58Agenda
- 6:36What is a sandbox?
- 8:24Sandbox my own code?!
- 9:49Java Security Manager
- 14:32java.io.File
- 15:03java.lang.SecurityManager
- 15:16Security Manager Summary
- 16:47Elasticsearch & the security manager
- 17:27Plugins & modules
- 18:33Elasticsearch startup
- 21:04Do not run as root
- 21:46Seccomp - prevent process forks
- 24:47seccomp sandbox
- 25:19Bootstrap checks
- 28:22Mark sensitive settings
- 29:20Register all your settings
- 33:30Resources
related talks
47mSecuring a search engine while maintaining usability
26mFinding Alternatives to Security Manager
44mSecuring the JVM
42mHidden security features of the JVM - everything you didn’t know and more
48mHidden Security Features of the JVM - Everything You Didn’t Know and More
43mSecurity Architecture of the Java Platform
32mELC 2013 Security: Best Practices for Embedded Systems
24mRuntime Security: Challenges & Solution Space