search

cockpit-project / cockpit

Cockpit is a web-based graphical interface for servers.
http://www.cockpit-project.org/
GNU Lesser General Public License v2.1
10.96k stars 1.1k forks source link

Add a test for namespace tampering #20831

Open gordonmessmer opened 1 month ago

gordonmessmer commented 1 month ago

The xz-utils attack involved an ELF library that parsed and modified the global offset table of the OpenSSH server during the runtime linking phase of startup.

I have developed a tool that examines the global offset table of a Linux process to look for signs of similar tampering, and I am adding tests to a variety of Fedora packages to run the tool in order to alert maintainers if a similar attack is detected in the future. (For example: https://src.fedoraproject.org/tests/nginx/pull-request/5)

I'd like to add that tests to cockpit, but I could use some feedback because the arrangement of tests for the Fedora package are a little unusual. Most of the tests I've added have been straightforward: tmt and beakerlib. But the tests for cockpit instead run the test suite from the upstream project.

Would you prefer that I re-write the test and open a PR here in the github project, or should I add the test to Fedora's test repo?

If I contribute the test here on GitHub, which test directory makes the most sense to you? Is a Python test script preferred?

Thanks for any guidance you can provide.

martinpitt commented 1 month ago

Thanks @gordonmessmer! That seems like a nice additional test. It would be mostly useful for downstream (Fedora, etc.), like you already proposed in https://src.fedoraproject.org/rpms/cockpit/pull-request/281 , but for us the downstream git is purely mechanical/automation -- we keep all our specs, tests, etc. in the upstream repository.

We do use tmt tests, with a top-level plan and the tmt test metadata and scripts in https://github.com/cockpit-project/cockpit/tree/main/test/browser . We don't use beakerlib, and pleeease don't introduce that -- even if you just put the five commands into a set -eux shell script, that's still much preferable to us. If your tool has a Python interface, that works as well of course (our integration tests are in Python, so we test-depend on that anyway).

So from our POV the best way would be to submit an upstream PR here, then the new test will automatically run in tmt/Testing Farm on Fedora and CentOS. The tests are automatically synced to Fedora and RHEL downstream on every release then.

Thank you!