event-generator
event-generator copied to clipboard
falcosecurity
event for detecting Terminal shell inside container.
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
/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.
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?
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
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).
- Gasper can create container like this
- It can delete containers too . (we can use it to delete container after event execution)
- It can execute command inside container.
- 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!!
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.
@FedeDP, yes, depending on Gasper is not useful. I provided it as an example of how I am considering implementing this change.
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
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.