Add systemd configurations to strengthen OS core security #17107
Conversation
Signed-off-by: Rajat Gupta <[email protected]>
RajatGupta02
requested review from
anasalkouz,
andrross,
ashking94,
Bukhtawar,
CEHENKLE,
cwperks,
dblock,
dbwiddis,
gbbafna,
jainankitk,
kotwanikunal,
linuxpi,
mch2,
msfroh,
nknize,
owaiskazi19,
reta,
Rishikesh1159,
sachinpkale,
saratvemulapalli,
shwetathareja,
sohami and
VachaShah
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #17107 +/- ##
============================================
- Coverage 72.30% 72.28% -0.03%
+ Complexity 65482 65414 -68
============================================
Files 5309 5309
Lines 304324 304324
Branches 44132 44132
============================================
- Hits 220056 219995 -61
+ Misses 66259 66254 -5
- Partials 18009 18075 +66 ☔ View full report in Codecov by Sentry. |
|
@RajatGupta02 If this is targeting 3.0 can you add an entry in the CHANGELOG for 3.0? |
| ReadOnlyPaths=/etc/os-release /usr/lib/os-release /etc/system-release | ||
|
|
||
| ## Allow read access to Linux IO stats | ||
| ReadOnlyPaths=/proc/self/mountinfo /proc/diskstats |
There was a problem hiding this comment.
Sorry @RajatGupta02 , I am wondering how does these conflicting settings
ReadOnlyPaths=/proc/self/mountinfo /proc/diskstats
and
ProtectProc=invisible
resolve?
There was a problem hiding this comment.
ProtectProc=invisible limits the visibility of /proc entries to the process itself whereas ReadOnlyPaths enforces a read-only policy, but it does not hide or restrict visibility.
So, in this case the service can read from /proc/self/mountinfo and /proc/diskstats, but it cannot write to them due to ReadOnlyPaths, these paths are not hidden by ProtectProc=invisible because they are specific files the service is allowed to access.
| ProtectClock=true # Prevent tampering with the system clock | ||
|
|
||
| # Socket restrictions | ||
| SocketBindAllow=tcp:9200 |
There was a problem hiding this comment.
So in general, we cannot hardcode ports: those could be changed in configuration, plus if I am not mistaken, OpenSearch will pick next free port automatically if 9200/9300 are busy.
There was a problem hiding this comment.
So in general, we cannot hardcode ports: those could be changed in configuration
which essentially means we cannot use these configurations. Should we rely on the java agent #16731 for socket and file restrictions?
There was a problem hiding this comment.
which essentially means we cannot use these configurations. Should we rely on the java agent #16731 for socket and file restrictions?
Indeed, the security policy does dynamic port configuration (during bootstrap), the agent would help here for sure
There was a problem hiding this comment.
I think we can still keep these three lines commented and with a doc comment, stating syncing it with opensearch port configurations
There was a problem hiding this comment.
to reduce the contention here and keep the ball-rollin, I propose two options --
- (preferred) Keep the currently proposed configuration and revise it with GRPC support.
- Remove the
SocketBindAllowandSocketBindDenyfor now and come back to it later.
If we decide to merge PR #16731 sockets permissions would be covered and we may not them in systemd.
There was a problem hiding this comment.
@reta let me know what you think.
There was a problem hiding this comment.
cc @rmuir for additional feedback.
There was a problem hiding this comment.
Remove the
SocketBindAllowandSocketBindDenyfor now and come back to it later.
@kumargu I think this is (sadly) the best option (taking into account the proliferation of the auxiliary transports being introduced as we speak).
There was a problem hiding this comment.
Ok. lets remove the socket permissions.
Signed-off-by: Rajat Gupta <[email protected]>
Signed-off-by: Rajat Gupta <[email protected]>
There was a problem hiding this comment.
can we remove the diff from this file? we can update our docs to use the template based config for more advanced security option. That would also prevent this change to be a breaking change.
This reverts commit 71b2584. Signed-off-by: Rajat Gupta <[email protected]>
|
❌ Gradle check result for c694f75: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Signed-off-by: Rajat Gupta <[email protected]>
|
❌ Gradle check result for 7c0402c: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for d784b96: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Description
Aims to strengthen the OS core security by using a stronger systemd unit configuration. The changes implement a form of sandboxing via systemd, protecting the system from potential vulnerabilities in the core or untrusted code (such as plugins).
Will be working on adding tests as suggested in the RFC: #1687
Related Issues
#16634
Supporting References
#16729
#1687
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.