OS-8352: Fake out Linux's SECCOMP to allow elasticsearch8 to run in LX zones


Issue Type:New Feature
Priority:4 - Normal
Created at:2022-02-11T20:23:52.868Z
Updated at:2022-02-15T21:04:03.776Z


Created by:Dan McDonald
Reported by:Dan McDonald
Assigned to:Dan McDonald


Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2022-02-15T21:04:03.769Z)

Fix Versions

2022-02-24 Linda (Release Date: 2022-02-24)

Related Links


Reported as https://github.com/joyent/illumos-joyent/pull/383, PR in https://github.com/joyent/illumos-joyent/pull/384.

Basically, elasticsearch8 uses a PR_SET_SECCOMP BFP macro (SECCOMP_MODE_FILTER) to prevent fork/exec.  In the absence of running this natively (where its Java code actually HAS Solaris-10-or-better privilege drops), lying about it may be sufficient, especially if elasticsearch has its own LX zone and nothing else.


Comment by Dan McDonald
Created at 2022-02-13T20:09:56.046Z
Updated at 2022-02-13T20:30:55.607Z

One more-recent exchange of the PR is useful to see here.  I'm quoted, Steve (the PR filer) is speaking below...


what is the consequence of faking a valid return of SECCOMP that doesn't actually add any BPF rules? … I looked at https://github.com/elastic/elasticsearch/ and it appears that SECCOMP is used to prevent fork/exec.

Yes, that's my understanding too. Looking at the git blame of that part of the Elasticsearch code, the reason it was added appears to be general security hardening, rather than to block a specific known behavior.

In their words, "This is just another level of security, java's security manager is not perfect, and there are often bugs in java itself, so it would good to have another level of defense."

If you're worried about that, perhaps elasticsearch native might be in order. … Is there a reason you can't run ES8 in a native zone? (or is it just that Elastic doesn't build it for instant deployment?)

Oh, I spent months fighting Elasticsearch in a native joyent-brand zone, and ended up here because patching SmartOS LX seemed like a simpler solution… :^]

Building a recent-ish version of Elasticsearch on Solaris requires patching a lot of files, which I worked my way through. Once I got it to build, I was running into subtler problems (hangs/timeouts and memory leaks) which don't happen when running the same Elasticsearch version inside an LX zone.

setting bootstrap.system_call_filter to false. may also override a need for this change.

Yes, that's true for Elasticsearch 7.x, and that's what we're currently doing in order to run Elasticsearch 7.x in an LX zone.

But in Elasticsearch 8.0 they removed the bootstrap.system_call_filter setting, so it's no longer possible to bypass that check.