I think a big part of the solution of this entire problem is some form of sandboxing. That way, if one of your sandboxes gets a virus, it won’t have access to information that is outside of that sandbox, and you can delete the virus by deleting the sandbox. At least in Linux, when you install something as a flatpak, it’s automatically in a sandbox. Another example is that some game launchers can automatically launch games in their own sandbox.
Of course, then you have the issue that certain programs have access to tons of personal data and also get used all over the place, like web browsers. Even if you install those in sandboxes, I’m not sure how you can protect yourself, apart from really locking it down and then vigilantly cleaning the directories that they can see. But that’s a lot of extra work. A good solution would be more automatic.
At least in Linux, when you install something as a flatpak, it’s automatically in a sandbox. Another example is that some game launchers can automatically launch games in their own sandbox.
Even then, however, often you have to give those flatpaks access to more system resources to work, which reduces the effectiveness of the sandbox and give viruses other paths to escape from. It’s not a lot of flatpaks I’ve had to do this with, but for the ones I have, it’s been a pain and a little bit frustrating that I have to open access to certain system/user files for it to work.
Also, I’ve just had trouble with certain flatpaks and their packaging for a long time now, but I’ve had various issues that are frustrating with both flatpaks and appimages that I simply don’t have when installing from the apt repository. Sandboxing is useful in certain cases for sure, but maybe not for everything sadly.
So, the way I see it, there are three layers of managing security for sandboxes. There is the developer. There is the distribution system. And then, there is the user.
Flathub gives warnings at the top of each app’s page. Ideally, they’d block publishing of apps that need a dangerous amount of permission, rather than just warning the user, but I understand why they don’t. I think they need like a flatpak secure mode that removes dangerous settings when installing a flatpak, and then they add to the top of their pages which apps don’t work with their safe installs.
I think then, that the future of flatpak security could evolve to alleviate the problems you mentioned. For one, as flatpak adoption increases, developers will end up at least looking at their flathub pages and have a desire to reduce those warnings.
Because right now, too much burden is placed on the user. I’m hoping that the technology will evolve to put all of the burden on the developer and the distribution system.
Unfortunately Linux had quite a few kernel level local privilege escalation issues recently. The sandboxes use the same kernel as the host. However, still better to have a sandbox.
Also webbrowsers a use sandboxing for ages and split privileges between multiple processes but can still have critical security issues.
Even full blown VMs sometimes have issues that allow escape to the hypervisor.
I still really like sandboxing and I’m not a huge fan of antivirus solutions, just saying it’s not a magic bullet.
Something easy you can do for web browsers is just have at least two installed: one that you use for personal info and trustworthy sites, and the other that you use for unknown/sketchy sites.
I think a big part of the solution of this entire problem is some form of sandboxing. That way, if one of your sandboxes gets a virus, it won’t have access to information that is outside of that sandbox, and you can delete the virus by deleting the sandbox. At least in Linux, when you install something as a flatpak, it’s automatically in a sandbox. Another example is that some game launchers can automatically launch games in their own sandbox.
Of course, then you have the issue that certain programs have access to tons of personal data and also get used all over the place, like web browsers. Even if you install those in sandboxes, I’m not sure how you can protect yourself, apart from really locking it down and then vigilantly cleaning the directories that they can see. But that’s a lot of extra work. A good solution would be more automatic.
Even then, however, often you have to give those flatpaks access to more system resources to work, which reduces the effectiveness of the sandbox and give viruses other paths to escape from. It’s not a lot of flatpaks I’ve had to do this with, but for the ones I have, it’s been a pain and a little bit frustrating that I have to open access to certain system/user files for it to work.
Also, I’ve just had trouble with certain flatpaks and their packaging for a long time now, but I’ve had various issues that are frustrating with both flatpaks and appimages that I simply don’t have when installing from the apt repository. Sandboxing is useful in certain cases for sure, but maybe not for everything sadly.
So, the way I see it, there are three layers of managing security for sandboxes. There is the developer. There is the distribution system. And then, there is the user.
Flathub gives warnings at the top of each app’s page. Ideally, they’d block publishing of apps that need a dangerous amount of permission, rather than just warning the user, but I understand why they don’t. I think they need like a flatpak secure mode that removes dangerous settings when installing a flatpak, and then they add to the top of their pages which apps don’t work with their safe installs.
I think then, that the future of flatpak security could evolve to alleviate the problems you mentioned. For one, as flatpak adoption increases, developers will end up at least looking at their flathub pages and have a desire to reduce those warnings.
Because right now, too much burden is placed on the user. I’m hoping that the technology will evolve to put all of the burden on the developer and the distribution system.
Unfortunately Linux had quite a few kernel level local privilege escalation issues recently. The sandboxes use the same kernel as the host. However, still better to have a sandbox.
Also webbrowsers a use sandboxing for ages and split privileges between multiple processes but can still have critical security issues.
Even full blown VMs sometimes have issues that allow escape to the hypervisor.
I still really like sandboxing and I’m not a huge fan of antivirus solutions, just saying it’s not a magic bullet.
I did only say that I thought sandboxing was “a big part of the solution.”
Something easy you can do for web browsers is just have at least two installed: one that you use for personal info and trustworthy sites, and the other that you use for unknown/sketchy sites.