|
"It's not really simple. It's actually complex and having a general purpose computer be hardened enough for non-geek homeowners not to screw up (social engineering, security warnings fatigue, etc) is possibly an unsolvable problem." It's actually straight-forward based on lessons learned in high-assurance security: research and field-proven stuff that actually stopped pentesters vs common stuff that doesn't. Apple already gets far with iPhones and app stores despite having way less security than I'd advocate. Their Macs showed auto-configuration & easy everything with a UX experience that needs to be in secure computers. That's just through whitelisting, quality control for apps, and sandboxing. Weak but fairly effective. So, what's something better take? It takes POLA all through the architecture for one. Orange Book showed no apps must be able to write to most critical files of the system except specific, administrative ones. Secrets should be compartmentalized in partitions with code that uses them without leaks, esp covert channels. Turaya et al showed you could do that in a single partition most of the time. OpenVMS showed a transactional, versioned filesystem lets you dodge all kinds of bullets with broken installs, accidentally deleting stuff, and so on. Time Machine shows how to make other process, backups, easy as possible. It would be combined with above to make that safe where apps couldn't subvert it. With above + whitelisting, apps are neither likely to try to do damage nor will do damage to critical files. The next step is mapping user's intent to computers securely. CapDesk, a capability-secure desktop from Combex, shows us hints of how to do that with their PowerBox feature. It's basically a file dialog that, in the background, gives the app permission for just what user clicks on. OS or GUI manages it where app can't do crap with it. Trustworthy GUI's like Nitpicker GUI in Genode prevent spoofing of this or other windows plus screen scraping. So, they're trusted dialogs for key actions that people get used to and allow fine-grained permissions to be inferred. The next step is on the apps themselves. They're going to try all kinds of tricky stuff. Android permission model is a start on dealing with this. Could, as Common Criteria did, create profiles for specific types of apps that have just what permissions make sense for that type of app. Wouldn't be mandatory but profiles or certification to them could help users instantly determine security package is reasonable. Certification would be easy if it was a permission list, use of a safe language, avoidance of features marked risky (eg macros, ActiveX, or JavaScript), and so on. Any app using stuff like that leverages capability-model with extra compartmentalization. All apps in this model are written with a language using GC or safe, manual memory. Any JIT's are integrated with isolation and/or capability schemes. All that is enforced, a la CHERI or SAFE, down to the CPU with IO/MMU transparently managing tags on incoming or outgoing data. Hard for me to imagine easy hacks on systems that combine above principles. It will sound hard to some reader until they remember existing mainframe, desktop, and UNIX architectures are much more complicated than a Rust or Go app against a straight-forward API with a permission list and/or security policy. Or a set of OS components coded similarly. Side effect is extensions and maintenance become easier once you have OS in type-safe, memory-safe, concurrency-safe, modular language with isolation as default coding strategy. Note: This covers security at the software and firmware level. Attacks on transistors or RF through software are outside of scope as R&D is ongoing. |