Hacker News Reader

Comment by charcircuit | Hacker News Reader

This is a waste of time compared to investing in sandboxing which will actually protect users as opposed to stopping theoretical attacks. Fedora's sandbox capabilities for apps is so far behind other operating systems like Android that it is much more important of an area to address.

View on HN

Defaulting to Android-style nanny sandboxing ("you can't grant access to your Downloads folder because we say so" etc.) is unlikely to go over well with the average Linux distro userbase.

Also, maximally opt-in sandboxes for graphical applications have been possible for a while. Just use Podman and only mount your Wayland socket + any working files.

>Defaulting to Android-style nanny sandboxing ("you can't grant access to your Downloads folder because we say so" etc.) is unlikely to go over well with the average Linux distro userbase.

If you market it that way. Plenty of Linux users say they care about security, don't want maleware, etc. This is a step towards those desires. Users have been conditioned to use tools badly to designed for security for decades so there will be some growing pains, but it will get worse the longer people wait.

>Just use Podman and only mount your Wayland socket + any working files.

This won't work for the average user. Security needs to be accessible.

> Just use Podman and only mount your Wayland socket + any working files.

If only it was that simple…

Why isn't it?

All files pokes a big hole, really you want portals. You probably also want audio. And perhaps graphics acceleration depending on the software, and other limited hardware access. And dbus (but sandboxed proxy access). Probably some global config from the host as well (fonts, themes, cursor). And…well maybe there’s more but the point is it depends on the software. Maybe it is that simply sometimes. Often it’s not for non-trivial applications.

I am yet to see a form of sandboxing for the desktop that is not:

a) effectively useless

or b) makes me want to throw my computer through the window and replace it with a 1990's device (still more useful than your average Android).

I think you have to do both sandboxing and this.

Both are good for security, but prioritization is important. The areas that are weakest in terms of security should get the most attention.

That assumes that there is a fixed amount of effort and resources to be split between the two things—that there is always opportunity cost.

When it comes to community efforts, it’s rarely the case that all things have opportunity cost—people who contribute effort for X would not have necessarily done so for Y.

The Fedora Project is of course not a purely community effort, so I don’t know exactly how that applies here. But just wanted to point out that prioritization and opportunity cost don’t always work like you suggested.

Flatpak, which Fedora Workstation uses by default, is already very similar in capabilities to Android's sandboxing system.

If you want security through compartmentalization, you should consider Qubes OS, my daily driver, https://qubes-os.org.

This only secures between vms. This side steps the problem and people can still easily run multiple applications in the same qube.

It's impossible to isolate applications inside one VM as securely as with Qubes virtualization. You should not rely on intra-VM hardening if you really care about security. Having said that, Qubes does provide ways to harden the VMs: https://forum.qubes-os.org/t/hardening-qubes-os/4935/3, https://forum.qubes-os.org/t/replacing-passwordless-root-wit....

People may want to have multiple apps work together. It makes sense to have security within a qube itself than to just declare it a free for all.

If the apps work together, they typically belong to the same security domain / trust level. Do you have examples when you still have to isolate them from each other?

Even if things are on the same trust level that doesn't mean that if one gets compromised I don't care that it affects the 2nd.

So just run them in different VMs?

Apart from that, any hardening in Fedora can be utilized inside a Fedora VM on Qubes. Qubes doesn't force you to use VMs with no isolation inside.

But then the files can't be shared.

Qubes has such functionality.

And you just deduced why sandboxing as it is implemented today is really pointless for the desktop .

I'm using Qubes as my daily driver on my desktop, so no.

What do you get from it? Specially considering that from above "programs that work together go in the same context"..

What I get from it: https://forum.qubes-os.org/t/whats-your-system-layout-like/8...

Two official examples of how one could benefit from Qubes:

https://www.qubes-os.org/news/2022/10/28/how-to-organize-you...

and

https://blog.invisiblethings.org/2011/03/13/partitioning-my-...

> Fedora's sandbox capabilities for apps

Do you mean Flatpaks or something else?

Sure, that is one solution, but it still needs a lot of work both to patch up holes in it and to fix apps to be better designed in regards to security.

Don't let perfect be the enemy of good? Flatpak is not perfect, but it has steadily improved security over the years. When I first used Flatpak, most applications had their sandboxes wide-open (because they were not compatible with sandboxing). Nowadays a lot of Flatpaks have much more limited sandboxes.

Reply on news.ycombinator.com