> If one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement.
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.
Man I just discovered this as a good guide on how to exceed the normal limits on Linux kernel modules.
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)
> how to exceed the normal limits on Linux kernel modules.
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)
> 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 one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement.
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.
They checked with their lawyers first… lol.
Pretty sure all laws are null and void in their mind.
It's probably an old joke, but heard it here first. LOL
I don't know about you, but for ethical reasons, I only allow libre rootkits to run on my systems.
Do you compile them yourself then? For possible arch specific optimizations
Ah this is so interesting. Rootkits are difficult to implement already, and RE them definitely is another level. Now we have a guidance.
Previously discussed at https://news.ycombinator.com/item?id=46498658
Man I just discovered this as a good guide on how to exceed the normal limits on Linux kernel modules.
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)
> how to exceed the normal limits on Linux kernel modules.
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)
> 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).
chroot or namespaces/containers?