Model Capabilities in the Analyses

[samarth-aws]

Google's new capslock tool contains the ability to reason about the "capabilities" of various functions and packages in the Go standard library. It would be nice if we could have the dataflow analyses reason about these same capabilities to be able to prove more powerful propositions.

For example, a possible proposition that can be proven via the taint analysis is: "no data that is read from a network can be used to modify the system state or file system". Without the capabilities feature, you would have to manually list every possible function/method/interface that can perform a network read or modify the system state.

Example config file:

taint-tracking-problems:
  -
    sources:
      - capability: "NETWORK"
    sinks:
      - capability: "FILES"
      - capability: "MODIFY_SYSTEM_STATE"

[victornicolet]

That sounds good. We can also combine capability with the other code identifier fields, for example I think it would make sense to add a package name, or the context.

For example:

taint-tracking-problems:
  -
    sources:
      - context: "customerDataHandlingPackage"
         capability: "NETWORK"
    sinks:
      - package: "logging"
         capability: "FILES"
      - capability: "MODIFY_SYSTEM_STATE"

to only view functions used in the fictional "customerDataHandlingPackage" with NETWORK capacity as sources, but if functions with NETWORK capability are called somewhere else, this is fine. Then the other refinement would mean the functions defined in logging that handle files are sinks.

[github-actions[bot]]

Stale issue message