bpf: store thread leader caps during fork and reduce false positives

Store the thread leader caps during fork so we can check later
if capabilities changed during the execve, just before the execve hook
point where we collect new capabilities and a new exec_id.

Right now during fork they are zeroed in the execve_map which make it
unreliable to detect if they changed between the fork and the final
execve.

Any hook just before the execve could report that they changed even if
they did not, this is the case of a privileged that is as an example
executing sudo or su.

An event will be generated that capabilities did change (raised) but in
reality they did not. As they were zero'ed the caps change comparison
will be performed against zero which will always succeed.

Fix this by storing caps during fork, and ensure that we only report
positive cases.

Signed-off-by: Djalal Harouni <[email protected]>

bpf/process/bpf_fork.c

@@ -22,6 +22,7 @@ BPF_KPROBE(event_wake_up_new_task, struct task_struct *task)
 {
 	struct execve_map_value *curr, *parent;
 	struct msg_clone_event msg;
+	struct msg_capabilities caps;
 	u64 msg_size = sizeof(struct msg_clone_event);
 	u32 tgid = 0;
 
@@ -56,6 +57,15 @@ BPF_KPROBE(event_wake_up_new_task, struct task_struct *task)
 	memcpy(&curr->bin, &parent->bin, sizeof(curr->bin));
 	curr->pkey = parent->key;
 
+	/* Store the thread leader capabilities so we can check later
+	 * before the execve hook point if they changed or not.
+	 * This needs to be converted later to credentials.
+	 */
+	get_current_subj_caps(&caps, task);
+	curr->caps.permitted = caps.permitted;
+	curr->caps.effective = caps.effective;
+	curr->caps.inheritable = caps.inheritable;
+
 	/* Setup the msg_clone_event and sent to the user. */
 	msg.common.op = MSG_OP_CLONE;
 	msg.common.size = msg_size;