Mem capture event has no dependencies

[AlonZivony]

Description

Went over the captures code, and noticed that the capture_mem event has no dependencies other than send_bin.

CaptureMem: {
		id:       CaptureMem,
		id32Bit:  Sys32Undefined,
		name:     "capture_mem",
		version:  NewVersion(1, 0, 0),
		internal: true,
		dependencies: Dependencies{
			tailCalls: []TailCall{
				{"prog_array", "send_bin", []uint32{TailSendBin}},
			},
		},
	},

This means that unless the probes it depends on are loaded by other event, it won't be triggered.
It depends on the security_file_mprotect kprobe, so it should be added.
Moreover, the security_file_mprotect is using the should_trace function, which means that only if a policy chose the scope it will capture it. This does not match our current capture logic, which should only use its own filters.

SEC("kprobe/security_file_mprotect")
int BPF_KPROBE(trace_security_file_mprotect)
{
    bin_args_t bin_args = {};

    program_data_t p = {};
    if (!init_program_data(&p, ctx))
        return 0;

    if (!should_trace(&p))
        return 0;

Output of tracee version:

f3fa64f0d3bd8c8203dd8199c182375f78d295ec

Output of uname -a:

(paste your output here)

Additional details

[geyslan]

Moreover, the security_file_mprotect is using the should_trace function, which means that only if a policy chose the scope it will capture it. This does not match our current capture logic, which should only use its own filters.

There are plans to bring capture into policies entirely, isn't right @yanivagman?

[yanivagman]

Moreover, the security_file_mprotect is using the should_trace function, which means that only if a policy chose the scope it will capture it. This does not match our current capture logic, which should only use its own filters.

There are plans to bring capture into policies entirely, isn't right @yanivagman?

Yes. We will need to fully revisit the capture code when we will do that