Ask HN: Globally Unique OS
4 comments
Yes. ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomiza...) is a form of that.
Even if you don't want to give up the ability to compile new software, you could go much further, for example by permuting the system call table, enum values used in API's, field order, or argument order, or by changing the ABI. That would stop binary payloads in their tracks.
Disadvantage is that lots of code may make assumptions about either of these. So, each of such changes has a small risk that it exposes bugs in the code you intend to compile.
Changing the API also is an option, as it would truly require an attacker to tailor their malware for your particular OS. Problem is that it would require you to port all the software you intend to run to it. Net effect likely is that it is way more work for you to do than for a would-be attacker to break.
You could go even further by permuting or completely changing your CPU's instruction set, but that would kill any programs that generate code (native code compilers, many interpreters)
It still wouldn't guarantee you complete protection, though. If breaking your system is enticing enough, people may figure out its instruction set and ABI through trial and error and lots and lots of perseverance.
Even if you don't want to give up the ability to compile new software, you could go much further, for example by permuting the system call table, enum values used in API's, field order, or argument order, or by changing the ABI. That would stop binary payloads in their tracks.
Disadvantage is that lots of code may make assumptions about either of these. So, each of such changes has a small risk that it exposes bugs in the code you intend to compile.
Changing the API also is an option, as it would truly require an attacker to tailor their malware for your particular OS. Problem is that it would require you to port all the software you intend to run to it. Net effect likely is that it is way more work for you to do than for a would-be attacker to break.
You could go even further by permuting or completely changing your CPU's instruction set, but that would kill any programs that generate code (native code compilers, many interpreters)
It still wouldn't guarantee you complete protection, though. If breaking your system is enticing enough, people may figure out its instruction set and ABI through trial and error and lots and lots of perseverance.
There is Urbit: https://urbit.org/
Certain Linux live CDs usually have a read only filesystem and are useful for tasks where you don't want to leave a trace, and everything is flushed from RAM after use. Ubuntu, for example, allows a user to try out the O.S without installing and is a great way to 'trash the hotel room' and then shutdown leaving no trace of your actions. Any files you create, for example will be wiped, and the kernel is exactly the same when you restart the system cleanly. Just to be safe, I would recommend booting from read-only media like an actual read-only CD so nothing can persist.
Yes, code signing (https://en.wikipedia.org/wiki/Code_signing) accomplishes this. It's why you rarely see malicious code running on iPhones -- iOS won't load code into memory at all unless it's signed (except in very special cases like the JavaScript virtual machine, which has to generate code on the fly for performance).
Shouldn't there be a way to take a base image and obfuscate or otherwise rearrange the base system in a way that all the code compiled on the image would work but any new code that is introduced would not work?
Obviously, there are many limitations to this, but wouldn't having a "globally unique os" protect you from malicious code infecting your system?