Improve visibility on the `ioctl` events
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 argument field).
for example, here an example of C code to set a network interface in promiscuos mode:
ifr.ifr_flags |= IFF_PROMISC;
if (ioctl(sock, SIOCSIFFLAGS, &ifr) == -1) {
perror("Failed to set promiscuous mode");
close(sock);
exit(1);
}
this is what we see in Falco:
14:19:29.179213999: Warning IOCTL event (evt.args=fd=3(<4>) request=8913 argument=7FFE4A0E97B0 fd.type=ipv4 fd.name= fd.sockfamily=ip proc.name=set-promiscous)
14:19:29.179219373: Warning IOCTL event (evt.args=fd=3(<4>) request=8914 argument=7FFE4A0E97B0 fd.type=ipv4 fd.name= fd.sockfamily=ip proc.name=set-promiscous)
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
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 possible ioctl commands for all possible devices would be a huge task.
I think we can reproduce in some way what sock_do_ioctl check if the cmd is relative to sockets is_socket_ioctl_cmd and 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.
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
Moving to next milestone, no bandwidth during this release cycle for this one. /milestone 0.19.0
/milestone 0.20.0
/milestone 0.21.0 No luck again for the current release cycle :/
As above :( we haven't got much developer "spare" time lately... /milestone 0.22.0
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