New transformer: `getopt(<args>, <optstring>)`

Motivation

By introducing a transformer that works like the C getopt() function, rules authors can more easily match and handle POSIX command-line arguments. This addition will streamline the creation of rules involving command-line options, ensuring greater flexibility and accuracy in rule writing.

Feature

Introduce a getopt(<args>, <optstring>) transformer to handle command-line arguments, mimicking the functionality of the C getopt() function.

Usage examples:

(n, t) in getopt(proc.args, "nt:")
getopt(proc.args, "nt:")[t] = val
getopt(proc.args, "nt:") intersects (n, t)

Alternatives

Doing nothing and sticking with the current way of handling this does not seem a compelling alternative:

- rule: Netcat Remote Code Execution in Container
  desc: > 
    Netcat Program runs inside container that allows remote code execution and may be utilized 
    as a part of a variety of reverse shell payload https://github.com/swisskyrepo/PayloadsAllTheThings/.
    These programs are of higher relevance as they are commonly installed on UNIX-like operating systems.
    Can fire in combination with the "Redirect STDOUT/STDIN to Network Connection in Container" 
    rule as it utilizes a different evt.type.
  condition: >
    spawned_process 
    and container 
    and ((proc.name = "nc" and (proc.cmdline contains " -e" or 
                                proc.cmdline contains " -c")) or
         (proc.name = "ncat" and (proc.args contains "--sh-exec" or 
                                  proc.args contains "--exec" or proc.args contains "-e " or
                                  proc.args contains "-c " or proc.args contains "--lua-exec"))
         )

Additional context

Design consideration: it is yet to be decided whether the getopt(<args>, <optstring>) transformer should mimic the getopt_long() function (which also accepts long options starting with two dashes) or if both getopt and getopt_long transformers should be introduced. This design choice can be deferred to the implementation stage.

References:

cc @darryk10 @loresuso

I am rooting for this new feature! Unfortunately, sometimes we can't make rules precisely on a syscall, and we end up building it on the command line (proc.cmdline) which is most of the time very tricky and easily bypassable for a number of reasons:

sometimes we need to check whether or not a group of options was specified (let's say a b c). Some tools will allow -abc, -a -b -c or also any other combination (like -bca). Nowadays, we should enumerate all the possible sequences to detect this. (n, t) in getopt(proc.args, "nt:") would totally solve this use case.
sometimes we would like to use our operators (like startswith, endswith or even contains) just on the value of the option and not the whole command line. So I strongly support also implementing getopt(proc.args, "nt:")[t] = val. Not sure if it can be implemented this way due to the [] but we can certainly think about how to make it happen

Lastly, if we are going in this direction, I would say that implementing getopt_long shouldn't be that hard and will let us complete the picture of making stronger detections on command line arguments. 🎉

falcosecurity / libs

New transformer: `getopt(<args>, <optstring>)` #1928