@TheEvilSkeleton The claim about security is flat out wrong.
File system access *is* full access.
If you can write to the file system, you can write a script, mark it executable, and tweak ~/.profile etc to run it on startup. This doesn't even require being able to mark a file executable, because you can simply add e.g. 'python malicious.py' to the end of the login script.
@TheEvilSkeleton More generally: anything that an application outside of flatpak can do, or anything inside of ANY of your "sandboxes" can do, can be done by *EVERY* one of your "sandboxes".
Heck, the easier option: write a small python script to listen for local text on a TCP port, and add starting it to .profile. In the malicious flatpak, write arbitrary commands to that port if it's open. If it's not, just wait until the next time the user reboots.
@pixelherodev we can see that this requires some extra steps right? The application cannot interface with the OnlineAccounts framework so it needs some workaround.
I'm not saying that it protects us from everything, because it clearly doesn't. I even made it clear that those permissions are problematic. The entire point was that it "requires extra steps [...] to gain access to my *other* personal information means that Flatpak can prevent bad actors a little bit with filesystem=host/home."
Security is possible. The failure of a single model does not prove otherwise.
Absolute security is actually quite *trivial*: turn off your computer, and never turn it back on.
The hard part is getting the functionality *without* the risk. Flatpak errs on the side of greater risk, functionality, and performance. Other models do the opposite.
My issue is only that people *pretend* flatpak is secure. It's not *meant* to be
I happen to quite like Plan 9's model, even if the implementation has issues (which are being solved right now!).
The only way to expose a service is through the file namespace. e.g. /net/ether0 is the ethernet stack, /net/ether1 is wifi, /mnt/factotum is the authentication daemon (think SSH agent but better), etc.
The namespace is *per-process (group)*. Want to disable network access for a script? `unmount /net && ./sandboxed`.
@pixelherodev @TheEvilSkeleton I have looked into plan9 on a superficial level and didn't understand the benefits of using it considering that it's basically a research system that's as stuck in the past as Unix based OSes with much more difficulty to install and run. I keep an open mind and reserve the right to change that opinion as I learn more.
I think linux and other OSes have a lot of catching up to do....
We had arm64 support before Ubuntu did! (True story, though I wasn't actually involved at the time, so "we" is perhaps a strong term.)
There's a lot of user-facing benefits, not least of which is seamlessly using a bunch of different computers together (e.g. laptop and desktop).
While there's plenty Linux can do that Plan 9 can't, there's also plenty Plan 9 can do that Linux can't.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.