RFD: Ensure code executed on the worker is confined#7127
RFD: Ensure code executed on the worker is confined#7127d3flex wants to merge 1 commit intoos-autoinst:masterfrom
Conversation
okurz
left a comment
There was a problem hiding this comment.
content looks good although I don't think we should commit this file into the repo at the current state.
|
|
||
| ## Investigation | ||
|
|
||
| To demonstrate the attack surface I wrote a test module (`tests/install/explore.pm`) that uses standard testapi calls (`script_run`, `upload_logs`) alongside direct Perl code to do sensitive things from inside the worker process on the host side. |
There was a problem hiding this comment.
I wrote a test module (
tests/install/explore.pm)
where can I find this?
There was a problem hiding this comment.
that not really important. I will add something similar to the openqa-in-opena as suggested in the RFD.
Martchus
left a comment
There was a problem hiding this comment.
For this to become part of our documentation you should avoid the use of "I". Maybe that's also not strictly necessary right now.
It would be interesting to test the isolation of tests runs from each other. I think it would be easily possible to restrict accessible directories even more so tests would only be able to read needed files from the system and from their own pool directory (but not pool directories of other worker slots).
It would also be interesting to test whether it works with the cache service or whether further settings need to be added.
| ## Investigation | ||
|
|
||
| To demonstrate the attack surface I wrote a test module (`tests/install/explore.pm`) that uses standard testapi calls (`script_run`, `upload_logs`) alongside direct Perl code to do sensitive things from inside the worker process on the host side. | ||
| This covers the main ways a malicious test module could exploit the worker: testapi calls that run commands in the VM but also give access to the host process, direct host file reads, and leaking files via `upload_logs` to the WebUI. |
There was a problem hiding this comment.
| This covers the main ways a malicious test module could exploit the worker: testapi calls that run commands in the VM but also give access to the host process, direct host file reads, and leaking files via `upload_logs` to the WebUI. | |
| This covers the main ways a malicious test module could exploit the worker: testapi calls that run commands in the VM but also give access to the host process, direct host file reads, and leaking files via `upload_logs` to the web UI. |
|
|
||
| ### systemd hardening — tested and working | ||
|
|
||
| I added standard systemd hardening directives to the worker unit. This solution seems to be the simplier less efortless to great value approach, which should be applied first . |
There was a problem hiding this comment.
"less efortless to great value approach" is incomprehensible.
As I stated in #7127 (review) I don't see the benefit of submitting this to the repo. |
Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
b62b5d7 to
2a1ec03
Compare
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Provide a set of scripts which explore the confined capabilities of the workers. There are two main approaches: using the test API to read/write from within the SUT and the Host level operations using system(). RFD: os-autoinst/openQA#7127 Issue: https://progress.opensuse.org/issues/194717 Signed-off-by: Ioannis Bonatakis <ybonatakis@suse.com>
Issue: https://progress.opensuse.org/issues/194717