Hacker News Reader

Comment by mikewarot | Hacker News Reader

Maybe this will finally get people over the hump and adopt OSs based on capability based security. Being required to give a program a whitelist at runtime is almost foolproof, for current classes of fools.

View on HN

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?

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

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.

People will use the equivalent of audit2allow https://linux.die.net/man/1/audit2allow and not go the extra mile of defining fine-grained capabilities to reduce the attack surface to a minimum.

    {
        "permissions": {
            "allow": [
            "Bash(bash:*)",
            ],
            "deny": []
        }
    }

Problem is if people are vibecoding with these tools then the capability "can write to local folder" is safe but once that code is deployed it may have wider consequences. Anything. Any piece of data can be a confused deputy these days.

This type of security is an improvement but doesn’t actually address all the possible risks. Say, if the capabilities you need to complete a useful, intended action match with those that could be used to perform a harmful, fraudulent action.

Have you, or anyone, ever lived with such a system?

For human beings, they sound like a nightmare.

We're already getting a taste of it right now with modern systems.

Becoming numb to "enter admin password to continue" prompts, getting generic "$program needs $right/privilege on your system -- OK?".

"Uh, what does this mean? What if I say no? What if I say YES!?"

"Sorry, $program will utterly refuse to run without $right. So, you're SOL."

Allow location tracking, all phone tracking, allow cookies.

"YES! YES! YES! MAKE IT STOP!"

My browser routinely asks me to enable location awareness. For arbitrary web sites, and won't seem to take "No, Heck no, not ever" as a response.

Meanwhile, I did that "show your sky" cool little web site, and it seemed to know exactly where I am (likely from my IP).

Why does my IDE need admin to install on my Mac?

Capability based systems are swell on paper. But, not so sure how they will work in practice.

This is only a problem when implemented by entities who have no interest in actually solving the problem. In the case of apps, it has been obvious for years that you shouldn't outright tell the app whether a permission was granted (because even aside from outright malice, developers will take the lazy option to error out instead of making their app handle permission denials robustly), every capability needs to have at least one "sandbox" implementation: lie about GPS location, throw away the data they stored after 10 minutes, give them a valid but empty (or fictitious) contacts list, etc.

That is because they are badly designed. A system that is better designed will not have these problems. Myself and other people have mentioned some ways to make it better; I think that redesigning the entire computer would fix this and many other problems.

One thing that could be done is to specify the interface and intention instead of the implementation, and then any implementation would be connected to it; e.g. if it requests video input then it does not necessarily need to be a camera, and may be a video file, still picture, a filter that will modify the data received by the camera, video output from another program, etc.

>Have you, or anyone, ever lived with such a system?

Yes, I live with a few of them, actually, just not computer related.

The power delivery in my house is a capabilities based system. I can plug any old hand-made lamp from a garage sale in, and know it won't burn down my house by overloading the wires in the wall. Every outlet has a capability, and it's easy peasy to use.

Another capability based system I use is cash, the not so mighty US Dollar. If I want to hand you $10 for the above mentioned lamp at your garage sale, I don't risk also giving away the title to my house, or all of my bank balance, etc... the most I can lose is the $10 capability. (It's all about the Hamilton's Baby)

The system you describe, with all the needless questions, isn't capabilities, it's permission flags, and horrible. We ALL hate them.

As for usable capabilities, if Raymond Chen and his team at Microsoft chose to do so, they could implement a Win32 compatible set of powerboxes to replace/augment/shim the standard file open/save system supplied dialogs. This would then allow you to run standard Win32 GUI programs without further modifications to the code, or changing the way the programs work.

Someone more fluent in C/C++ than me could do the same with Genode for Linux GUI programs.

I have no idea what a capabilities based command line would look like. EROS and KeyKOS did it, though... perhaps it would be something like the command lines in mainframes.

> My browser routinely asks me to enable location awareness. For arbitrary web sites, and won't seem to take "No, Heck no, not ever" as a response.

Firefox lets you disable this (and similar permissions like notifications, camera etc) with a checkbox in the settings. It's a bit hidden in a dialog, under Permissions.

I wish I could share your optimism.

Reply on news.ycombinator.com