I would be interested to know what access rights .deb (apt) packages have by default. Does this vary depending on the app, or do all apps have the same access rights?
Do .deb packages have access to all user files and all system files?
With flatseal, you can set specific permissions for flatpaks, and I'm wondering what you would have to set so that a flatpak has exactly the same access rights as a .deb package.
Generally, they all have the same access and rights - with exceptions, but they do not have access to all user or all system files.
When you install a .deb package, it is run under the permissions of the logged in user. It cannot write to system files and we see this often when a user posts questions about their application not having permission and we must advise them to elevate to root.
All of it is guided by the UNIX permissions standards.
You could set --filesystem=host, then allow network access, then allow each individual device access you need. This would need to be done individually on each flatpak package.
To install a apt package I need root rights. Will the package still only be installed with my user rights even though elevated to root when running 'sudo apt install...'?
Installing and running are separate actions.
Installing includes the necessity to write files to root - for example, writing the .desktop file in /usr/share/applications
That is not the same action as Running the Application.
When a flatpak app doesn't work because of missing permissions, how do you know which device or file you need to add?
To me, your explanation sounded as if flatpaks would be given too many rights if they were granted access to all user files or system files as not even .deb packages have these rights, which are built into the system.
Honestly, I am not sure. I do not use Flatpak's. I have tried, many times.
It ends up the same way each time.
If using a flatpak and you are missing permissions to a device, it is Likely Obvious what is missing. For example, if it needs to print but cannot see the printer. If it is Steam flatpak, but cannot see your Storage Drive device.
If it is a meteorological app, but lacks access to your sensors. So on. You would probably set each up as you go, rather than doing it all at once.
There comes a point where a person must apply the cost to benefit ratio.
Being security conscious does not mean, cutting off your hands.
In current culture, many users feel a sense of paranoia about security not because there are so many threats out there seeking to get them... But because largely, they have little understanding of how it all works, so overcompensate in demanding greater security.
What do you mean with this sentence? Do you mean it is good to grant access to all users and system files if it is not clear which permissions are missing?
E.g. recently a flatpak clock app didn't work because of missing permissions. What to do then?
When you give the flatpak access to all users or system files, are this read only or also write and execute rights?
Granting permissions is a choice upon the user.
What I mean is - for anything, there is a cost - and there is a benefit.
An easy example: Chemotherapy.
For the patient, there is a benefit - killing cancer cells and saving the life of the patient.
There is a cost - it kills healthy cells, too. It can lead to complications or other ailments.
The ratio: If the cancer is caught very early on and removable with other methods - the cost of the chemotherapy is too high for the benefit of killing cells that can be removed in a more gentle way.
If it is metastasized and the patient is ill and weak, adding the illness caused by Chemotherapy may be too high a cost, for little chance of benefit.
In computer security, the cost for more Security is user access, data integrity and system communication. The benefit is... well... security.
The more security you add, the more you risk data corruption and complete data loss (Some of these hashes are, for all intents and purposes, unbreakable), restrictive access to needed tools and restrictions on needed system communication - all of which can interrupt proper workflow. It's a balancing act or a trade off.
Hmm, unfortunately that doesn't really help me with what to do in a specific case and how to proceed in order to get a system that is as secure as possible but also functional when advising other users with flatpak problems.
Nevertheless, thank you very much for your efforts!
Unfortunately, I can't test this extensively because I don't use Flatpaks on my systems due to very limited storage space, and Flatpaks usually fail to install in the live session due to insufficient RAM.
In a specific case, you will know more about the specifics of that case.
How to proceed can only be to explain the concepts and leave the choice to the end user.
They will ask questions - you will give answers - and they will make up their own minds.
But if it helps, the reality is that flatpak's influence on security is minimal, at best.
Technically, you can say it is "more secure." So is drowning the computer in the bathtub.
But lacking interested actors that are looking to exploit non-flatpak packages, and somehow magically able to bypass all other UNIX security, for the purpose of invading a home users computer that might have some funny vacation photos and some steam games installed... The threat level just is not there for little payoff and a massive resource hungry attack vector.
I mean... on my worst day, sinful, even... I am utterly boring to a hacker.
And Flatpak will not protect your data by its nature. So no luck, there.
I do kind of wish Flatpak apps went the route that Android apps do when installing and running. I know that sounds weird, but all I mean by that is, since you open and run the app, when you do something that it may not have access to, it asks you if you would like to give it permission, and either allow it or disallow it. You don't install a "AppSeal" application to change the permissions before hand to allow it, it asks you as the need arises.
There would definitely be problems with that approach on linux, but I do think doing something in that vein would help alleviate a lot of the the permissions problems. You could also still install / have installed by default Flatseal (or bake it into the OS if so desired) to modify / audit what permissions apps do or do not have.