dotnet: consider emitting namespace, class, method, and field/property names referenced by an assembly

[mike-hunhoff]

(1) e.g. emit the following for System.IO.File::OpenRead:

- namespace: System.IO
- class: File
- method: OpenRead

(2) be more explicit to avoid FPs resulting from naming conflicts, e.g.:

- namespace: System.IO
- class: System.IO.File
- method: System.IO.File::OpenRead

and for properties, e.g. (more discussion in #939):

- namespace: System.Net
- class: System.Net.WebRequest
- property: System.Net.WebRequest::Method

I like option 2 the best, and I think this would apply to both file and function scopes and both internal and external references.

[mike-hunhoff]

we can then write rules like:

rule:
  meta:
    name: manipulate files in dotnet
    namespace: host-interaction/file-system
    scope: function
  features:
    - and:
      - class: System.IO.File

[mr-tz]

Do we need the namespace field for (2)? Can you think of rules where we would use that in rules right now?

[mike-hunhoff]

Including the namespace for imported classes is probably overkill. However, including user-defined namespaces may facilitate malware family detection. I don't have a specific example for the latter.

[mike-hunhoff]

I propose the following:

• emit class, method, and property/field names for imported classes
• emit namespace, class, method, and property/field names for user-defined classes

[mr-tz]

Ah, yeah, that could be neat to detect on namespaces. For simplicity I'd then say we emit namespace, class, method, and property/field names for all classes?!

[mike-hunhoff]

I agree; we should keep it simple by extracting the same for all classes. so, emit the following for all classes referenced at file and function scope:

• namespace
• class
• method/field/property

see #939 for discussion on emitting references to properties/fields.

[mike-hunhoff]

this may require introducing new features, including:

• namespace
• class
• field/property??
• method??

see #939 for field/property.

unsure if we need method or if we can simply reuse api.

[williballenthin]

see #939 for property access.
#1030 covers namespace/class/method.