291–300 of 316 posts
Earlier quoted context omitted.
Flatpaks unlike Snaps are actually sandboxed properly.
Full or no filesystem access is very, very far from proper sandboxing.
Earlier quoted context omitted.
Because there are pros and cons for each type of packaging but native distro packages and Flatpak will go-exist. It does already on my machine. Distribution packages: + necessary for base system + small memory requirement + small package size + all checked by distro + work well together + on fix, fixes it for all o lot of work for maintainers downstream - bugs hard to figure out for upstream - problematic with closed…
The biggest minus of containers for me, including Flatpak, are that even with xdg desktop portal workarounds they still fail to actually integrate into the desktop and make or break features that depend on this simply don't work. And because it's a container it's nigh impossible to debug and find a fix. In the end containers are even more fragile than depending on system libs and fighting future shock.
Desktop portals are not "workarounds", they are the new correct APIs to use
Earlier quoted context omitted.
> It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your syste The good news is there is a solution to this. The trusted system shows a file picker, and then grants access to the sandboxes application. This is called the File Chooser Portal. https://docs.flatpak.org/en/latest/portal-api-reference.html...
I didn't realize this existed, it seems a lot like what Apple is doing for the photo gallery in recent iOS versions. That's a nice extra safety feature. I suppose additional security features inspired by mobile systems couldn't hurt either. Like a pop-up whenever something accesses the clipboard.
I just hope flatpak sandboxing works well...
Flatpak will be the recommended way to get / install LibreOffice on RHEL and Fedora. In https://lists.fedoraproject.org/archives/list/devel@lists.fe... it states: "the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term." Install instructions are already written: https://acces…
I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. If you want to give that application access to everything your user has access to, that’s fine, but it s…
But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies.
OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.
Earlier quoted context omitted.
Bespoke RPMs that have to be patched and modified for distros by a small group of maintainers have issues too.
Redhat is just falling. It was a pain doing packages 25 years ago, comparatively it is simple now. Frankly, the flatpak will have issues as well, but those will be outside of Redhat's direct control. Which means the end game, will be a redhat flatpak.
Earlier quoted context omitted.
The biggest minus of containers for me, including Flatpak, are that even with xdg desktop portal workarounds they still fail to actually integrate into the desktop and make or break features that depend on this simply don't work. And because it's a container it's nigh impossible to debug and find a fix. In the end containers are even more fragile than depending on system libs and fighting future shock.
> xdg desktop portal workarounds Desktop portals are not "workarounds", they are the new correct APIs to use
>Portals are the framework for securely accessing resources from outside an application sandbox. They provide a range of common features to applications, including: Determining network status, opening a file with a file chooser, opening URIs, taking screenshots and screencasts [...]
https://lwn.net/Articles/694291/
All things being containerized messes up which require workarounds. xdg desktop portal attempts to provide these but most of the time it fails to do so fully.
Earlier quoted context omitted.
> It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere. It does make sense for at least one distro to be offering this, as there are numerous reasons to favor the traditional linux distro way of doing things. Flatpak is better for a lot of use cases, but it's missing a lot by not having a centralized system of check…
New maintainers picked up LibreOffice, so that will still happen, since LibreOffice wasn't retired from Fedora.
Earlier quoted context omitted.
I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server. This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
Yeah, that's like the poster child of sandboxing; I am very much supposing that my word processor is not allowed to touch arbitrary files.
Earlier quoted context omitted.
I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
You're ignoring the supply chain side. RHEL RPMs are signed by Red Hat. Flatpaks are signed by... whoever happens to maintain that flatpak.
Earlier quoted context omitted.
As far as I know, Flatpak offers a fair amount of control over sandboxing. It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your system. The alternative might be giving it access to one particular directories, and then copying files there when you want to work on them. But that's already pretty cumbersom…
That's roughly what our workflow does (DFARS requires it or something like it for CUI) and this story annoys me because the entire selling point of RHEL (which is what we use) is that you aren't having to audit a bunch of random upstreams because they do it for you. It's why their going all-in on flatpak was such a surprise to a lot of us.