I’m really excited about Adrian Vovk’s approach to making GnomeOS a general purpose and approachable FOSS OS. I’m especially excited about Vovk’s desire for greater default security and wanted to know if there has been any collaboration between the Gnome OS team and SecureBlue? SecureBlue seems to have a strong foundation to build on top of and it seems like a natural fit towards Gnome OS’s security goals. If not, is GnomeOS’s security approach / roadmap documented anywhere?
Worth noting that Secureblue focuses on security first, and usability later. Example: it disables xwayland.
1 Like
I’ve understood their purpose as
secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.
If I’m understanding the intent - secureblue recognizes the usability downsides to their approach and are not opposed to making informed compromises in the name of practicality.
My hope is GnomeOS would adopt secureblue’s security features and help smooth out some of the rough edges. For example, it sounds like some of SecureBlue’s critiques of Flatpak are being addressed with Flatpak-Next and Portals.
Be sure that security features are the priority. But, like you said, the goal is to make GNOME OS a general purpose OS. And, like @tragivictoria said, xwayland is disabled, which is still needed for gaming.
Regarding flatpak, the developers of secureblue seems to not have understand something which have been addressed since a long time. The permission model they are referring too is a bad model. They want to ask the user to grant access to static permissions. The problem is that naive users - those who are installing apps without knowing them previously - can’t really decide if a static permission is really useful or not. If a user does not allow a specific permission, the user is taking the risk to have some app features not working. And, if the app is not working as they want, then they will probably go back to allow the permission they denied. I concur that being directly able to further sandbox a not fully-sandboxed app is nice, but that isn’t for all people, and the goal is to have things usable, the user to not have to search what they should do only to use an app. That’s why portals are meant for. Anyway, if they have been able to implement what they wanted, then there is nothing to do flatpak side. Regarding the users requesting to change the default permission set for flatpaks, this relates to repositories, not to flatpak nor xdp. In terms of improvements, there is only need to have more portals and to be sure that the user has the option to choose the fine-grained permission (of type “Allow Once”, which allow the user to keep control on what happen) and not only to allow or deny a global permission. That’s the case of the screenshot portal where the user has not the option to be always asked to confirm screenshot taking, as the app is, globally, asking the user to freely take screenshots or to not use the app.
This mischaracterizes Secureblue. They like Portals too, but the problem is that Portals are too limited in their current state. That leads to apps needing static permissions in the manifest, including some really “dangerous” ones.
So, Secureblue includes a bunch of flatpak rules by default to remove these dangerous permissions from all apps. And that does break many apps, requiring users to tinker with static permissions. But on the whole, the security is better than what is default. It just requires users to be more technical and willing to live with the inconvenienes of better security.
I’m referring to the following:
Even better, permissions should be granted directly by the user at app runtime, like in Android.
It is this model that is not better, even if the current state of portals is not better either. In terms of security, what they have done is nice, but not so much because of tinkering (which can broke security). I mean, thinking that this model is better in terms of security is a little bit false for users in general. The current informing model - the one adopted by GNOME - is not better because users want to use apps, but can’t restrict apps directly (so their model). Both have advantages, but also weaknesses.
1 Like
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.