Add unprivileged and privileged subcommand to Elastic Agent#4621
Add unprivileged and privileged subcommand to Elastic Agent#4621ycombinator merged 29 commits intoelastic:mainfrom
unprivileged and privileged subcommand to Elastic Agent#4621Conversation
unprivileged and privileged subcommand to Elastic Agent
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
|
SonarQube you are correct about unit tests, but you are very wrong about integration tests... This has integration tests for both privileged and unprivileged going in both directions. |
| // cannot switch to unprivileged when Elastic Defend exists in the policy | ||
| err = ensureNoElasticDefend() |
There was a problem hiding this comment.
Normally osquery is running as privileged. Quite a lot of functionality will be unavailable if running unprivileged or returning different results.
Osqueryd also checks for "safe permissions" when it loads our custom extension.
When osquery launches, each path is evaluated for "safe permissions"
(extension executable files must be owned by root or Administrator)
and executed as a monitored child process
https://osquery.readthedocs.io/en/stable/deployment/extensions/#autoloading-extensions
If you observe a runtime error from osquery, Extension binary has unsafe permissions,
you have to lock down the filesystem permissions on the extension executable.
See the steps in "Extensions Binary Permissions," above.
https://osquery.readthedocs.io/en/stable/deployment/extensions/#troubleshooting
There was a problem hiding this comment.
For osquery, you should mark the integration as requiring root privileges like defend does in https://github.com/elastic/endpoint-package/blob/ce921805467ab55953adc3721e7db8581915bd35/package/endpoint/manifest.yml#L23-L25. You can also do this for individual data streams but I don't think that applies to OSquery.
You could also add a prevention to the spec file to prevent us from even starting osquery if you aren't root, but since it doesn't fundamentally not work when not root, this might not be necessary.
There was a problem hiding this comment.
If you do update the spec, you would want to update the agentbeat spec.
| return nil | ||
| } | ||
|
|
||
| func ensureNoServiceComponentIssues() error { |
There was a problem hiding this comment.
I don't think this has any test coverage. You could add a check in the endpoint test suite that the unprivileged command fails, or add a unit test.
There was a problem hiding this comment.
True I will add an integration test, as I would prefer to see a true scenario be tested.
|
I have validated manually that this works on macOS, because we do not have integration testing coverage on macOS. I was able to switch between the modes successfully and the vaults are handled properly. |
| return cmd | ||
| } | ||
|
|
||
| func unprivilegedCmd(streams *cli.IOStreams, cmd *cobra.Command) (err error) { |
There was a problem hiding this comment.
nit: seems like there's quite some repetition meaning this and privilegedCmd function
|
|
@ycombinator feel free to force merge this is required as it seems sonar coverage is the only missing condition. |
What does this PR do?
Adds a new
unprivilegedandprivilegedsubcommand that converts an installed Elastic Agent from privileged to unprivileged or back again.Why is it important?
To allow users to change the permission execution mode without having to re-install the Elastic Agent.
Checklist
[ ] I have made corresponding change to the default configuration files[ ] I have added tests that prove my fix is effective or that my feature works(will have integration tests)./changelog/fragmentsusing the changelog toolAuthor's Checklist
How to test this PR locally
Related issues