event for detecting Terminal shell inside container.

[h4l0gen]

Motivation
We have one stable rule in default-rules Terminal inside container. I feel it would be great to have an event about it in event-generator.

Feature
adding an event of detecting terminal shell inside container.

Alternatives

Additional context

[h4l0gen]

/assign @leogr @alacuku @jasondellaluce I want to discuss this event . I feel that we need this event for detecting terminal shell. Please provide your thoughts on it.

[leogr]

The difficulty of generating this event resides in the "container" part. Currently, the event generator does not have a means to launch a container. So, there's no simple way to generate this event (unless the event-generator is already running in a container).

@FedeDP @LucaGuerra any idea?

[h4l0gen]

Yes @leogr , actually i opened this issue to discuss on ways to create this event, with you. I am working on finding some ideas on this. Currently am trying to find some way with using proc.tty

[h4l0gen]

Hii @leogr @FedeDP @jasondellaluce @alacuku I want to propose an idea for spawning container functionality in event-generator using docker go API. As a member of this club, I worked on project Gasper in SDSLabs (student run technical club in IIT Roorkee).

1. Gasper can create container like this
2. It can delete containers too . (we can use it to delete container after event execution)
3. It can execute command inside container.
4. It can returns the logs from a docker container too.

This tool have MIT license too as per CNCF requirement.

we can manipulate this tool as per requirement of event-generator, by using this we have one additional functionality for event-generator and events for rules which requires container.

Please provide your thoughts regarding this idea.

Thank You!!

[FedeDP]

Well as far as i can see, that tool just leverages docker go client library, just like eg: driverkit does.
I see no point in depending on gasper when we can just directly use the docker library.

[h4l0gen]

@FedeDP, yes, depending on Gasper is not useful. I provided it as an example of how I am considering implementing this change.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale