56
File canary kill switch
(gitlab.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 25 Jun 2026
56 points (98.3% liked)
Linux
14131 readers
548 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 3 years ago
MODERATORS
This is really cool. I appreciate you sharing it. I'm currently building out my homelab to try out various softwares and scenarios, and one of the things I'm worried about is malicious software sneaking in, and compromising my LAN.
In the case that something does, this essentiallyy provides a tripwire which leaves all the evidence intact while stopping the bleed (unless it has a VM escape, but that's another story).
In any case, this is very useful and I'm really glad you made it. Thanks!
Yes you can
-send-sigstopto SIGSTOP the process and then do whatever you'd like on your-on-touched-exesuch as attach via ptrace, dump all memory, etc. My current one will send a notification and dump the memory of the offending process.Definitely pay attention to the warning about running this on a server. With a KVM attached in a home lab you should be able to easily recover I guess. I think you could also set yourself up a little UDP service to SIGUSR1 the daemon since incoming packets are not dropped, but I haven't tested that.
[Note: intelligent malware can handle the SIGSTOP fairly easily. You could try to move the process to a new cgroup and then freeze the cgroup, as well, but there is a lot to consider here obviously]
Uh yeah, that's the whole idea. I can always just bring it offline and mount the root as a separate disk to a different VM to investigate.
Or even just log in via serial console, but that's not a capability I have coded in yet.
I guess what I'm saying is I match the "really know what you're doing" criteria.