shaded-enmity
Joined 9 years ago
Joined 9 years ago
> securelevel may no longer be lowered except by init
> The list of securelevel's effects may not be comprehensive.
So yes, it's a nice sandbox that can help prevent accidents, but doesn't sound like something you should rely on for actual defense.
That's generally called pivoting and has nothing to do with method of persistence of the malicious code.
OP makes a point that certain systems move or have moved away from giving root user the ability to extend/modify kernel code at runtime via kernel modules, my argument is that none of that matters since root user can still extend/modify kernel code at runtime via binary patching.
#include <stdio.h>
#include <stdlib.h>
static void begin() __attribute__((constructor));
void begin() {
unsetenv("LD_PRELOAD");
}
Build with: gcc -shared -fpie -o library.so library.c
Test: LD_PRELOAD=~/library.so env | grep LD_PRELOAD2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs
EU should be there to set goals, not to dictate implementation.
How does the demon attain the knowledge of what is "fast" and "slow" without continuous observation (and thus interaction) with the particles. Velocity is just function of position over time, so the demon needs at least 2 samples to make the most basic approximation. Where is the entropy for doing that coming from? How does the interference of the measuring apparatus factor into the whole process - what if the sole act of measurement changes the state of the particle from "fast" to "slow" or vice versa? Do we need to measure twice? But what if the second measurement causes the transition it was meant to detect?