Too bad the author picked the MIT license. Had they picked (A)GPL, it would have forced the criminals to distribute a copy of LICENSE.TXT alongside their improved copy of the source code on systems they compromise. Failing this, using it in that way would be both a crime and an instance of copyright infringement.
Although, it occurs to me that if they don't give credits to the original author, it's also already a copyright infringement under the MIT.
The anti-tivoization clause in Version 3 would allow users to modify and replace the rootkit with their own, more or less malicious version, even if it would otherwise violate copyright law.
Well-made distinction; +1.
Pretty sure all laws are null and void in their mind.
Can a kernel be compiled with Ftrace forced off? If it can be disabled at runtime, I take it it's not mandatory for the kernel to work. And I don't just mean off: I mean striping the Ftrace code path (dead code elimination or whatever).
I'm also interested in other measures, like a unified kernel moreover without the ability to load modules but this is not what my question is about. I'd like to know if Ftrace can just be turned off for good at kernel compile time.
grep FTRACE /boot/config*
Been working on a derviative which hooks the VFS to allow dynamically remapping file paths on a per process basis so I can force badly behaved apps to load custom TLS certificates (looking at you Bazil builds in nixpkgs).
(If anyone knows something which already does this it would save me a lot of yak shaving)
Uh, what limits? I'm not aware of anything that would stop your module, once probed, from reaching around the back of the kernel and futzing around in the internals of another driver/device in a completely unrelated subsystem, or subsystem internals. SoC/SoM vendors love to pull that kind of crap in their BSPs.
> hooks the VFS to allow dynamically remapping file paths on a per process basis
Instead of messing with kernel VFS internals, you could try:
- patching the offending application or package (ideally make the path configurable and contribute that back upstream)
- running the application in a mount namespace and bind-mount something over the path
- use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)
I think I would literally recompile libc to patch fopen/open/openat long before I would even begin to consider writing a kernel module to mess with filesystem paths on a per-process basis.
I feel like if you find yourself seriously considering writing a kernel module then you are either contributing to kernel development, or have embarked on an adventure specifically to learn about kernel internals, or have take a very wrong turn.
chroot or namespaces/containers?
Hah
This effort is more useful to up and coming defenders and security researchers than attackers by far.
"I don't know what happened to your computer but you seem to be saying someone hacked your computer and installed some software and you found acme.com mentioned on it. This was not done by me. acme.com is open source software that is freely available to anyone. This is the same as if someone installed software on your computer that mentions the google chrome web browser - that would not indicate google had anything to do with that action, since google chrome is freely available too."
> I think I would literally recompile libc to patch fopen/open/openat
That's literally the functionality that LD_PRELOAD provides without having to recompile libc.
It's not like I didn't try this stuff.
Seriously, you're doing it wrong. Just hook the relevant system call and be done with it. Your usecase is literally one of the first eBPF tutorials that comes up when looking for information about modifying system call arguments. https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/m...
which i find very entertaining, saying "a sign can't stop a criminal!" as if that's not the case with any law enforced via threat of criminal prosecution
Another great one is "drug free zone" seen plastered all over a seedy highschool. Drugs are blanket illegal everywhere here. The US has made an art form out of persecuting drug users. We've peddled our "war on drugs" globally. What could possibly be the point of posting such a sign?
If you want a real answer, its increased penalties / extra charges if caught in the "zone".