Hacker News Reader

Comment by guy98238710 | Hacker News Reader

I think the main limitation is currently in Flatpak sandbox. Lots of apps assume control over the whole computer (IDEs, Rust, Android tooling). Lots of apps still rely on X11, which allows trivial sandbox escape. And then a lot of apps just ask for full access to your home folder or even to the whole filesystem, just so that they can open documents. Even if you try to restrict it manually, you can only make an access blacklist, not a whitelist. It's like trying to plug holes in a sieve. You are one update away from Flatpak poking another hole in the sandbox at the request of the app developer.

View on HN

JFYI, firejail can do all of that. It can start each application in a separate xserver (giving you a choice from several implementations), deny access to everything with whitelisting (or do the reverse — your choice). The profiles are really easy to read and write, and it already covers a lot of popular stuff.

Still hoping for something other than Firejail to come along: The way profiles are designed is brittle and an order-dependent override hell, and it's common to use denylists vs. allowlists.

Firejail is a setuid binary with tons of attack surface and has had a number of privescs itself[1], unlike something like the lower-level Bubblewrap tool.

I'm glad it exists, though - it's the only mature solution other than Flatpak that has proper dbus filtering, among other things.

[1]: https://www.cvedetails.com/vulnerability-list/vendor_id-1619...

> And then a lot of apps just ask for full access to your home folder or even to the whole filesystem, just so that they can open documents.

Therein lies IMO the biggest problem with application security on desktop Linux. Just like selinux, apparmor and other similar security tools *someone* has to globally deny access to permissions, break things in the process and find the minimum number of permissions required for the app to function.

Many users are not going to do this and (lazy or uninterested?) developers (package maintainers?) don't want to do that work either.

AppArmor policies can be few hundred lines. Do people write these from scratch, or there is a repository for good policies?

Couldn’t package managers install and enforce such policies?

Debian has apparmor-profiles but it’s too immature to enforce by default.

And the various portals are used to satisfy user consent implicitly. If you are clicking something in the open file portal the permission is granted. I found this pretty weird when I first encountered it.

Reply on news.ycombinator.com