Hacker News Reader

Comment by zahlman | Hacker News Reader

Can I confidently (i.e. with reason to trust the source) install one today from boot media, expect my applications to just work, and have a proper GUI experience out of box?

View on HN

No, and I'm surprised it hasn't happened by now. Genode was my hope for this, but they seem to be going away from a self hosting OS/development system.

Any application you've got assumes authority to access everything, and thus just won't work. I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files, but that hasn't happened in the 5 years[1] I've been waiting. (Well, far more than that... here's 14 years ago[2])

This problem was solved back in the 1970s and early 80s... and we're now 40+ years out, still stuck trusting all the code we write.

[1] https://news.ycombinator.com/item?id=25428345

[2] https://www.quora.com/What-is-the-most-important-question-or...

> I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files

Isn't this the idea behind Flatpak portals? Make your average app sandbox-compatible, except that your average bubblewrap/Flatpak sandbox sucks because it turns out the average app is shit and you often need `filesystem=host` or `filesystem=home` to barely work.

It reminds me of that XKCD: https://xkcd.com/1200/

Or perhaps more relevantly to the overall thread: https://xkcd.com/2044/

Yes, Flatpak portals are an implementation of the powerbox pattern. They're still underutilized, though there are more portals specified than I realized at least: https://docs.flatpak.org/en/latest/portal-api-reference.html

That kind of thing (with careful UX design) is how you escape the sandbox cycle though; if you can grant access to resources implicitly as a result of a user action, you can avoid granting applications excessive permissions from the start.

(Now, you might also want your "app store" interface to prevent/discourage installation of apps with broad permissions by default as well. There's currently little incentive for a developer not to give themselves the keys to the kingdom.)

Note to self: don't name a project two letters 'ci' away from Genocide.

Qubes?

Way heavier weight, but it seems like the only realistic security layer on the horizon. VMs have it in their bones to be an isolation layer. Everything else has been trying to bolt security onto some fragile bones.

You can write completely secure code and run it in a locked down VM and it won't protect you from lethal trifecta attacks - these attacks work against systems with no bugs, that's the nature of the attack.

Sure, but if you set yourself up so a locked down VM has access to all three legs - that is going against the intention of Qubes. Qubes ideal is to have isolated VMs per "purpose" (defined by whatever granularity you require): one for nothing but banking, one just for email client, another for general web browsing, one for a password vault, etc. The more exposure to untrusted content (eg web browsing) the more locked down and limited data access it should have. Most Qubes/applications should not have any access to your private files so they have nothing to leak.

Then again, all theoretical on my part. I keep messing around with Qubes, but not enough to make it my daily driver.

If you give an agent access to any of those components without thinking about it you are going to get hacked.

If the VM has:

-Access to your private data

-Exposure to untrusted content

-The ability to externally communicate

Then it's not "locked down"

Depending on your security requirements you should have only one or two of those capabilities per VM

Reply on news.ycombinator.com