aquasecurity / tracee

Linux Runtime Security and Forensics using eBPF
https://aquasecurity.github.io/tracee/latest
Apache License 2.0
3.61k stars 416 forks source link

Parse additional syscall arguments #2336

Open AlonZivony opened 1 year ago

AlonZivony commented 1 year ago

We already decode some of the syscall arguments, but there are still some syscall arguments for which we don't decode the argument values although it can be useful.

NDStrahilevitz commented 1 year ago

This is a general problem we have across flag arguments see here #2190. If it's ok for you, it would be nice if you could make your solution extendible to the other events with flags arguments. Also, we now have access to the libbpfgo helpers in signatures so that may make the work easier in tracee itself too.

AlonZivony commented 1 year ago

The problem with what you propose is that each syscall has its own flags. You need to have a dedicated function for each type of flags to be able to parse them, so it isn't possible to make it a generic flags parsing.

We can create a generic function that get the event ID and parse the flags accordingly, but it will just call the dedicated functions behind the scenes... So this means in my opinion that creating a generic function is relevant to another issue and PR and not specifically to this issue.

NDStrahilevitz commented 1 year ago

We can create a generic function that get the event ID and parse the flags accordingly, but it will just call the dedicated functions behind the scenes... So this means in my opinion that creating a generic function is relevant to another issue and PR and not specifically to this issue.

This is what I mean, that the infrastructure you create for handling this event's flags can be later extended for other flag types. I'm aware that we have multiple flag types, IIRC between open and exec as well. I have a start for different argument types filtering (for the syscall argument need) here #2251, but if you propose something different I can also fit the solution there to yours.

AlonZivony commented 1 year ago

The only thing I can think of is like I wrote before - function that parse flags according to eventID+flags

func ParseFlags(eventID events.ID, flags int) (helpers.SystemFunctionArgument, error) {
    ...
   switch eventID {
   case events.Clone:
         return helpers.ParseCloneFlags(uint64(flags))
    ...
}

It might be a bit of a bad practice to return an interface though...

NDStrahilevitz commented 1 year ago

It might be a bit of a bad practice to return an interface though...

I actually think it's a good start for the internal mechanism. I think it would be best in a FlagsFilter, that would do this work, and we could use from libbpfgo OptionAreContainedInArgument since that already gives a bool check for the flags we want to be set, so we could skip the parsing. Then the options we check we can parse from the cli and store them per context (so for openat, O_RDONLY but for security_file_open maybe O_WRONLY).

AlonZivony commented 1 year ago

Yea I agree it sounds better than really parsing it. You do need to notice that sometimes there are values hidden in the flags, like HUGE_TLB size in the flags of the mmap syscall. That might require some deeper logic. But we can make the interface you propose to work with it.