I have never once wanted a desktop app to "take a picture". If I want to take a picture with my webcam I'll do it with a native utility I trust then open the file. This is a general principle: vetted native apps for privileged things, 3p junk in a HARD sandbox.
Conversation
But of course this is a replay of the FDO folks trying to recreate all the mistakes of Windows on the Linux Desktop, only this time it's recreating all the mistakes of Android... 🤦🤦🤦
1
They're trying to copy the way it works on Android although often based on how things worked in Android 4.4.x to 6.x rather than how they work now. That's just what they're trying to do and isn't really how things work. The way it usually works is apps opt-out of the sandboxing.
2
"Opt out of the sandboxing" is accepting the narrative that "self-contained applications" and "sandboxing" are the same problem domain. If you reject that, it's not a problem except in a ux sense (you need to manually bind-mount the files you want to access into the ns).
2
AppImage sticks to just providing self-contained applications and has existed for a long time.
Most of the point and the work on Flatpak seems to be bringing application sandboxing. Packaging up applications is part of it but more of an afterthought and secondary thing for them.
1
1
Another *nasty* problem facing Flatpak is that it has to support systems with SELinux not in use. It can’t rely on SELinux because not every distro supports SELinux. And Flatpak apps are usually native apps, unlike Android where everything uses abstracted APIs.
1
SELinux is an implementation detail on Android from app perspective and could be something else. There's a lot of value in declarative, static security policies.
Linux kernel has decided LSMs and eBPF obsolete doing things other ways so that's another major reason for it.
2
Android used to have gid-based socket restrictions similar to the grsecurity patches and a network usage monitoring kernel module, etc. All that stuff has been removed since it supports mainline kernels. Instead netd (but nothing else) can use a bpfloader program to use eBPF.
1
Just the direction things are headed for Linux. They had to replace a 40 line of code kernel patch and a 500 line of code kernel module with thousands of lines of userspace management code and thousands of lines of eBPF management and compilation stuff. I don't find it cleaner.
1
They only "had to" do that at all because it was the bad security model they inherited. Better would be not to have either.
1
The network usage monitoring isn't really part of the security model but rather properly monitoring and controlling application data usage. It's a mix of netfilter with eBPF code. They previously had a netfilter module handling everything and had to replace it to use mainline.
They used to have to teach netfilter about sandboxed apps and all the data usage / quota stuff properly.
Possible to do some things based on the per-profile-per-app uid/gid (combines user id + app id to get those) but netfilter is limited and just not really designed for it.
1
Socket restrictions are done with eBPF in order to prevent creating sockets/connections instead of just making the connections die as if there's a network issue. This was the entirety of the old way: github.com/GrapheneOS/ker. Now it's all complex eBPF stuff to avoid that patch.
OK, but you could just give each app its own virtual interface in its own network namespace, and watch the stats on the interface, and cut it off from the real network interface when you don't want it to have access.
1
The way it's wired up to netfilter gives a kind of push design since netfilter updates the per app stats as things happen without needing to poll for them.
It has to fit into the overall per-network metering, etc.
Network ns would be nice for per-profile localhost though.
2
1
Show replies