How to harden your entire os/application suite

First off, this is really just kind of thinking out loud and i am not a security expert at all… I’m just curious what your thoughts are.

I got to thinking about how the sandbox works. At the root of it all, the os is really just a resource divider. But the interconnection of the system and the applications is exactly what creates so much complexity and so many loop holes for maleware to penetrate… I don’t truly understand how the os allocates resources but why isn’t possible for an application to be given a hardened “shell” so to speak? This shell imo should include all the ram, files, etc. I would like to see a program query for a file (in the encrypted storage) be completed by the os in such a manner that decryption also verifies the code and data before injection into the shell for use by the program.

Basically, what im saying is why can’t we seperate the os from our data and prgrams in such a manner that malware intrusion never has a chance see decrypted data, or enter the shell where it can cause damage. The os would never even see any data… As far as the os knows, it just has memory and cpu resources that are absolutely not to be interfered with.

Kind of the opposite of the way the sandbox works in keeping bad prgrams contained, now we are putting good prgrams in the container and laughing at the malware that can’t get access to any resources. Any executable that doesn’t pass the code integrity test, or have a decryption key matching what your shells Require would instantly be terminated and removed.

I THINK this is sort of how some of the current windows security works… Specifically the code integrity portions… So if we have a hardened os via code integrity, hardened application shells that nothing can get into and out of without some sort of authentication, and then an encypted communication protocol for printing, external devices etc… Then how can malware ever get a foothold?

Would this takes a complete rewrite and rethinking of the way apps and os currently interact? Does it even make sense the way I’m describing it?

It doesn’t necessarily need a complete re-write though yes, building from the ground up would be the best choice. You make perfect sense and in fact, I can give an example of its application: Qubes OS.

Correct me if I’m wrong but the Qubes’ implementation is exactly what you meant:

Qubes takes an approach called security by compartmentalization, which allows you to compartmentalize the various parts of your digital life into securely isolated compartments called qubes.

This approach allows you to keep the different things you do on your computer securely separated from each other in isolated qubes so that one qube getting compromised won’t affect the others. For example, you might have one qube for visiting untrusted websites and a different qube for doing online banking. This way, if your untrusted browsing qube gets compromised by a malware-laden website, your online banking activities won’t be at risk. Similarly, if you’re concerned about malicious email attachments, Qubes can make it so that every attachment gets opened in its own single-use disposable qube. In this way, Qubes allows you to do everything on the same physical computer without having to worry about a single successful cyberattack taking down your entire digital life in one fell swoop.

Moreover, all of these isolated qubes are integrated into a single, usable system. Programs are isolated in their own separate qubes, but all windows are displayed in a single, unified desktop environment with unforgeable colored window borders so that you can easily identify windows from different security levels. Common attack vectors like network cards and USB controllers are isolated in their own hardware qubes while their functionality is preserved through secure networking, firewalls, and USB device management. Integrated file and clipboard copy and paste operations make it easy to work across various qubes without compromising security. The innovative Template system separates software installation from software use, allowing qubes to share a root filesystem without sacrificing security (and saving disk space, to boot). Qubes even allows you to sanitize PDFs and images in a few clicks. Users concerned about privacy will appreciate the integration of Whonix with Qubes, which makes it easy to use Tor securely, while those concerned about physical hardware attacks will benefit from Anti Evil Maid.

Thanks for the reply.

I looked into qubes a little bit, and your right. its very very similar to the approach that I had imagined in my mind. However, in there case, I still think the qubes are “infectable”…??.. maybe… its seems to me like its more of a sandbox approach, that could still allow malware to infect the sandbox, while not allowing that to reach out to other systems. same end result, different implementation. It just appears to me that they are only implementing current technology, in a segregated way. Im proposing a completely new layer of security, that does not exist yet.

As I have thought about this more and more, I have really just run myself in circles pointing out my limited knowledge of computer programming and os development. And I think I have added a bit more to my idea to make it more doable/reasonable

Let me back up a bit.

suppose you have your programs on an encrypted, read only drive. when you run a program, the OS would allocate memory and run a “ghost” of that program, fully loaded into ram, and cordoned off from any changes or code injections by malware. The program would have a unique “trust key” that would allow other sub programs enter its ram environment. IF malware did get onto the system, it would never have that trust key and would not be able to make changes to the ghost program… and it certainly would not be able to make changes to the original program locked into the read only drive space. (you could use the same trust system for updating the software on that drive)

take for example a cad software I use often like solidworks. Solidworks.exe is more so an “environment” to run lots and lots of sub programs, than it is a singular program for doing CAD work. In the particular case of malware, if it got onto your system now, it could almost easily inject code into one of those sub programs, and when solidworks runs it, now you have a critical security vulnerability. (ignore how it got on the pc in the first place)

by my method, The “solidworks.exe” program has 2 defenses. Primarily, is the code authentication portion that verifies all of its programs and sub programs have not been modified as they sit on the read only storage space. I assume this would have to take place with some sort of hash check or signature. Secondly, as the program runs, and a users calls up a sub program, solidworks itself (and this is important) NOT the os, would verify the trust key of that sub program before it is allowed to run in its environment. This would basically be an always on “trust but verify” situation.

so now you have like 4 or 5 layers of defense with minimal overhead. ( we have plenty of cpu and ram resources to handle this on a modern workstation, imo)

Now where I get a bit lost, is how the OS would play into all this, in a safe, and controlled way, such that it doesn’t leak the trust keys, or somehow spoof an improper result. as an example, explorer.exe is a common attack point. if a trusted program calls up an explorer process, then that process should also get a trust key to identify where it came from, where it goes, (and possibly an encryption layer), you would have to ensure that malware isnt sitting, waiting, trying to intercept one of those keys, thereby enabling its own explorer.exe process…however, if the malware can never get installed onto the known good read only storage media, then it would not be able to pass a hash check, and would be nullified. thereby never being able to steal the trust key in the first place. I might add, that if malware DID somehow manage to intercept a key, and started doing its own thing… then the program would not get the information it needed and therefore would submit a request for the exact same process… if this happens repeatedly, the antivirus should immediately be able to flag it.

i know… its complicated… there is multiple layers and angles from which to attack malware from and im probably not doing that good a job of explaining whats in my head. :slight_smile:

While I can’t say for certain that I would be correct, this system that you are thinking of requires a complete re-write particularly because you intend to run the program within a read only space. Most programs require interaction with various ‘modules’ as i would call them, and some create files on the fly. A read-only space won’t allow for this. I also don’t believe in a read-only program. I don’t think that that can be created. So long as it can be run, then it can be observed. In other words, it will have to interact outside one way or another regardless if it’s a ghost or not (how else do you intend to save your work?) and that in itself is a vector point.

One way I could think of to crash the system (ddos of sorts) would be to simply continue replicating (assuming read-only is improbable/implausible) and attempting to verify itself. Either it gets verified or it eventually creates enough jobs to overload the system. Kind of like a forkbomb. Then you’d have to reboot, launch the observer, catch the verification key, duplicate and apply the same logic to the program effectively gaining access. This is all hypothetical with no real technical basis though so hey, take it with a grain (or maybe a pinch) of salt.

So… As far programs running in a read only environment… I would have to clarify… The ghost program would not be read only. The initial app you install into your drive, once it’s installed… Its registry keys and data all becomes completely unchangeable (within reason) It lives in an environment of total impenetrability. ( things like config files could still be edited) when you “run” the program, your doing two thing, first, your loading all the files necessary into ram… Or perhaps another hard drive. Second, all the executables, child processes, dll’s, etc that are related to and called up by that program are also started… And each one of these items will be generated a unique key that is shared throughout the particular application and its children. This key woukd be generated via a hash of the original application installed. The os, would get the other side of the key and before execution of any of the child processes would verify the key. So now you have a fully operational “copy” of the program you loaded. Youre still running the same code, you just added a layer to it. If there is changes that need to be made to the original program,… Such as a user setting, the key would allow Verification of that change… And then the original updated program would be rehashed so it generates a new key the next time you load it.

Now… In the case of malware… It would have no way of Injecting code into any of these loaded files… Because it has no way of determining the key. Even if it manages to read the original program, which should be isolated, it wouldn’t have the password, or be able to generate the unique hash/key that would allow it to enter the programs space. This is assuming malware gets onto the system to begin with. Remeber the goal of this is not to keep that from happening, but to ensure that unknown executables cant actually infect any running process… In the case of polymorphic malware… The change of the program would also mean a change of the hash that should be able to be flagged.

Well, it does make infecting it harder, though I still don’t think it’s impenetrable. You did say it’s only meant to harden. I think it’s viable. Whether anyone would put enough effort to create one is another story.

Just one more layer… I think the biggest issue is how tightly or would have to be integrated with the os. It almost needs to be part of the kernel. How else would u get control of adding keys to all the processes.

…if one wanted towrite. Software pill Lee this. . What degree program would they be going for? Is this something that you would need more than a heavy programming back ground for?