[BUG] Capability missing for -c dir:<path>

[AsafEitani]

Prerequisites

• [x] This affects latest released version.
• [ ] This affects current development tree (origin/HEAD).
• [x] There isn't an issue describing the bug.

Select one OR another:

• [ ] I'm going to create a PR to solve this (assign to yourself).
• [x] Someone else should solve this.

Bug description

This is how I'm executing tracee (cmdline): sudo dist/tracee-ebpf -t e=init_module -c module -c dir:/home/eitani/malware This is the error I'm getting: 2022/07/18 15:02:42 error creating Tracee: error creating output path: mkdir /home/out: permission denied

Steps to reproduce

Steps to reproduce the issue:

1. run the above command
2. see the error

Context

Relevant information about my setup:

• Linux version:
• Linux kernel version:
• Tracee version (or commit id of your tree):
• LLVM version:
• Golang version:

Additional Information (files, logs, etc)

[NDStrahilevitz]

Possibly related: https://github.com/aquasecurity/tracee/pull/1958#issuecomment-1183341217 (with regards to tracee's file creation permissions).

[AlonZivony]

Your error is pretty weird, because it suppose to create the folder /home/eitani/malware/out, not /home/out. Might it be bug with the logic of creating the output folder?

[NDStrahilevitz]

From currently testing - this doesn't reproduce as late as commit 1224824a63742c0b67aed3a6e431a52341286615 (libbpfgo 0.8.0 update)

With a git bisect I found commit 2d2d100323697c7637bbb25da53d7466d15aaab6 to blame, which is PR #1819, so looks like changing to libcap broke this.

AND, moving ensureCapabilities to the end fixed this. So looks like we're missing some capability here. testing with sudo rm -rf /home/ubuntu/malware/ && tracee-ebpf -t e=init_module -c module -c dir:/home/ubuntu/malware

[NDStrahilevitz]

So relevant capability is CAP_DAC_OVERRIDE. Talked with @AlonZivony and there was also a conclusion that this isn't a bad thing, rather there may be a design fault in letting tracee writing anywhere it wants, removing this capability simply exposed this flaw now. There may be additional features broken because of this capability change.

I will open a new issue tracking this discussion, but perhaps we could close this. @yanivagman WDYT?

Potential fix for now: If we set a capture option we add this capability. But this would avoid the issue at hand.

[AlonZivony]

@yanivagman notice this will be even worst if we change user from root in the future.

[yanivagman]

I will open a new issue tracking this discussion, but perhaps we could close this. @yanivagman WDYT?

I think the user should be able to set a directory as he desires IF HE HAS THE RELEVANT PERMISSIONS when starting tracee. When creating the directory, we add an extra out subdirectory to avoid mistakenly overwriting/deleting the an already existing directory (when used with the clear-dir option).

A possible solution might be creating the directory with the correct permissions before dropping any extra capability. WDYT?

@yanivagman notice this will be even worst if we change user from root in the future.

Right. And we will find solutions for these problems as well :-)

[NDStrahilevitz]

A possible solution might be creating the directory with the correct permissions before dropping any extra capability. WDYT?

So there are actually two places where we create the dir, first is tracee-ebpf/main.go:232 and pkg/ebpf/tracee.go:395.

So if we run this mkdir before capability dropping, we would need to choose the first and move it. But maybe this should be part of tracee's internal business logic, since we define all captures later in the pipeline go there? I've opened relevant issues on #1990 and #1989

I think the user should be able to set a directory as he desires IF HE HAS THE RELEVANT PERMISSIONS when starting tracee.

But it's always root creating the directory in tracee, that would meanroot must create those dirs too. Then we need to document this. And when we move users from root it would be even worse because now the user can't supply their own path again. Setting up tracee would just get really complex.

Additionally we have many subsystems in tracee requiring file reads from /proc/fs and /sys/fs, for example in #1956. These also require certain privileges for the running user.