Add Stage0 RFC for new fields for fileless execution on Linux

[stanek-michal]

• Have you signed the contributor license agreement? - Yes
• Have you followed the contributor guidelines? - Yes
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process? - Yes
• If submitting code/script changes, have you verified all tests pass locally using make test? - N/A
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes? - N/A
• Is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed. - Yes
• Have you added an entry to the CHANGELOG.next.md? - N/A

[github-actions]

Hi!

We just realized that we haven't looked into this PR in a while. We're
sorry!

We're labeling this PR as Stale to make it hit our filters and
make sure we get back to it as soon as possible. In the meantime, it'd
be extremely helpful if you could take a look at it as well and confirm its
relevance. A simple comment with a nice emoji will be enough :+1.

Thank you for your contribution!

[stanek-michal]

Hi!

We just realized that we haven't looked into this PR in a while. We're sorry!

We're labeling this PR as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.

Thank you for your contribution!

commenting to un-stale

[mjwolf]

I think this is good for RFC stage 0, it has a defined use-case and the proposed fields and events represent well-known Linux concepts.

For the next RFC stage, you could also consider if this could be made more OS-agnostic. Some of these concepts could also apply to Windows or MacOS, so the descriptions could be made more generic to apply to others as well. The event types are also fairly low-level, while most existing types are higher level, so you could consider if they should go in the same namespace.

For now, I think the only thing it needs is to be renamed to RFC 0045

[mjwolf]

Could you change this, and the filename to 0045? RFC 0044 is taken now

[stanek-michal]

done

[mjwolf]

There's already a file.attributes list. Maybe these could be added to the attributes instead of having separate fields?

[stanek-michal]

That could work, maybe in that case the attribute could be called just "memfd" and "shmem".

[mjwolf]

A "process" and the "processes's executable file" are different things, and I think this might be mixing them too much. This could be renamed to make the separation more clear, but that's something to discuss in later stages.

[stanek-michal]

Yes, the inode_nlink can be a useful signal to detect anonymous file execution but it is quite low level and less transparent than the other ones. We could discuss in the next stage if we should rephrase it or just remove it for simplicity and rely on is_memfd as the only signal.

[stanek-michal]

Do we need a second ACK or can I merge this?

[mjwolf]

Do we need a second ACK or can I merge this?

For RFC stage 0, I think this is good, and I'll merge it soon. But for future work on this, I think it would be best to contribute to OpenTelemetry Semantic Conventions first, as we've outlined in the updated contribution process.

There have been some recent discussions in semantic-conventions around how OS-specific and lower-level concepts should be organized, and those would involve similar concepts as this RFC. Since the long-term goal is to have ECS and OpenTelemetry be inter-compatible, I think it would be best to work with semantic-conventions now, to avoid creating any conflicts between the schemas.

[stanek-michal]

Do we need a second ACK or can I merge this?

For RFC stage 0, I think this is good, and I'll merge it soon. But for future work on this, I think it would be best to contribute to OpenTelemetry Semantic Conventions first, as we've outlined in the updated contribution process.

There have been some recent discussions in semantic-conventions around how OS-specific and lower-level concepts should be organized, and those would involve similar concepts as this RFC. Since the long-term goal is to have ECS and OpenTelemetry be inter-compatible, I think it would be best to work with semantic-conventions now, to avoid creating any conflicts between the schemas.

Thanks for merging. I'll look into semantic conventions (which I also need to do for another project, so that's convenient!)