fuzz testing of KubeArmor

[nyrahul]

Feature Request

Short Description

KubeArmor is a security tool and thus security testing of KubeArmor itself is important/imperative.

Fuzz testing involves testing all/most combinations of external inputs to the subsystem. For example, KubeArmor policies are provided by the users and thus might have unwanted effects if the policies are incorrectly formed. The intention of the fuzz testing is to ensure that appropriate input set is derived by the test tool (Google's oss-fuzz is popular) and provided as input to KubeArmor. The execution is then profiled (either using pprof/other tools) to check for any anomalies and unwanted side effects of the execution.

Tasks:

• [ ] Identify/Prototype the fuzz testing tool to use (oss-fuzz, AFL are some popular choices)
• [ ] Generate input set that will guide the fuzz testing tool
• [ ] Identify a way to profile KubeArmor during execution (possibly using pprof + ...?)
• [ ] Identify components that will be fuzz tested. For example:
  • KubeArmor policy controller
  • KubeArmor operator
  • KubeArmor configmap handler
  • KubeArmor GRPC endpoints.
• [ ] Document the whole process to ensure repeatability for future versions
• [ ] Automation strategy for fuzz testing

[mastersans]

@DelusionalOptimist I'll more research regarding all the possible components of the project that would benefits with fuzzing and will share my findings.

[DelusionalOptimist]

Thanks @mastersans. Was great to know about your experience with fuzz testing in the community call. Looking forward to you findings!

[nyrahul]

@DelusionalOptimist I'll more research regarding all the possible components of the project that would benefits with fuzzing and will share my findings.

This would be amazing to get it done! Fuzzing is an interesting topic. One good reference is Cilium fuzzing audit report.

A good first step would be to simply use go fuzzing with KubeArmor ginkgo testsuites.

[mastersans]

@DelusionalOptimist I wanted to ask that the kubearmor configmap handler referred here, is it referred to THIS FUNCTION. ?

[DelusionalOptimist]

This function is the one where KubeArmor reads the configmap data - https://github.com/kubearmor/KubeArmor/blob/a5f584c38ee7cd674d1e95a3f7ce7842212dfe12/KubeArmor/core/kubeUpdate.go#L2361

[prady0t]

Here is a workflow example of how we can proceed :

• Finding fuzz targets: These are the functions whose input needs to be fuzz tested. For example here : https://github.com/kubearmor/KubeArmor/blob/a5f584c38ee7cd674d1e95a3f7ce7842212dfe12/KubeArmor/policy/policy.go#L24 (This could be a wrong/not-so-helpful example, I'm new to KubeArmor) We can fuzz test ContainerPolicy for different values of data taking valid json structures as initial values (seed corpus).
• Writing fuzzers: Once we know the fuzz target, we can write a fuzzer for it. Initial seed corpus values can be given according to the function definition.
• Check locally if they work.
• Integrate with OSS fuzz : OSS fuzz basically runs the fuzzer continoulsy until it finds an error, which is then reported. For setting up Kubearmor on OSS fuzz, we need to create a folder for Kubearmor inside projects directory. We can see a vast number of projects already using oss-fuzz here. This folder has essentially two files: a) A Dockerfile : to define the Docker image that OSS-Fuzz will use to build and run your fuzz targets, b) project.yaml : file to define the project configuration for OSS-Fuzz. Once we have our PR merged (on oss-fuzz repo) oss-fuzz will run the fuzzers (which are available) continously. For future additions of fuzzers, we will just have to modify the files accordingly such that they are discoverable by oss-fuzz. Any reported bug can then be fixed.

We can start by finding functions whose fuzz testing can potentially find vulnerabilities. We can look at the Cilium report (mentioned above) to find such functions in the Cilium repo and look for similar (if any) functions in KubeArmor.

[nyrahul]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

[prady0t]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

Do you think the function I mentioned above is a good one to write a fuzzer for?

[nyrahul]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

Do you think the function I mentioned above is a good one to write a fuzzer for?

KubeArmor receives external input in following ways:

1. Policy {ContainerPolicy, HostPolicy, GlobalPolicy}
2. ConfigMap
3. GRPC

It is best we start with any of these and your proposal to start with ContainerPolicy makes sense to me.

[prady0t]

I just opened a PR. This could be a starting point as to how we wand to test ContainerPolicy. We can add more seed values, conditions and logs for a better test.

[daemon1024]

Hey Folks, Thanks for the interest in the mentorship. We have certain prerequisites which we expect to be included in your application. Please include details or reference to a document for the said prerequisite in your Cover Letter / Mail to the mentors / Submit it in the issue thread / DM Mentors in CNCF Slack by 20 August 11:59PM IST

Following are the details.

Implement Fuzz testing for KubeArmor Components - https://mentorship.lfx.linuxfoundation.org/project/91bd7201-e83f-444c-9157-f82f4c56d060 Prerequisite: Write a sample fuzzer for any of your own Go project or for KubeArmor and run it with oss-fuzz base image More Details: https://google.github.io/oss-fuzz/getting-started/new-project-guide/go-lang/

[prady0t]

Hey @daemon1024 . We just have to write files so that our sample fuzzer is able to get compiled with oss-fuzz right? Running it can only be done once a PR (containing these files) sent to oss-fuzz repo, gets merged.