Repository navigation
Improve visibility on the ioctl events #1328
Description
Activity
ei @Biagio-Dipalma! The request makes sense! We will try to schedule some time for this in the next release. For the moment I will put the milestone
/milestone TBD
Here I think we can only get socket relative ioctl
cmd. Handling all possibleioctlcommands for all possible devices would be a huge task.I think we can reproduce in some way what sock_do_ioctl check if the
cmdis relative to socketsis_socket_ioctl_cmdand then convert types to a PPM notation, WDYT?Moving to 0.17.0.
/milestone 0.17.0/milestone 0.18.0
We had no time to work on this during the 0.17.0 release cycle.
24 remaining items
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
/remove-lifecycle stale
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
/remove-lifecycle stale
Motivation
This syscall can be handy to detect suspicious/malicious operations with network interfaces. To achieve this we need more details about the interface provided in the entry event: at the moment we see the memory address of the object (in the
argumentfield).for example, here an example of C code to set a network interface in promiscuos mode:
this is what we see in Falco:
Feature
in this case we might need to update the arguments to see the flags applied to the network interface and get only the malicious/suspicious ones.
Alternatives
Additional context