cross-posted from: https://lemmy.ndlug.org/post/1104312
The upcoming Ubuntu 24.10 operating system promises a new feature called “permissions prompting” for an extra layer of privacy and security.
The new permissions prompting feature in Ubuntu will let users control, manage, and understand the behavior of apps running on their machines. It leverages Ubuntu’s AppArmor implementation and enables fine-grained access control over unmodified binaries without having to change the app’s source code.
From Ubuntu Discourse: Ubuntu Desktop’s 24.10 Dev Cycle - Part 5: Introducing Permissions Prompting
This solution consists of two new seeded components in Ubuntu 24.10, prompting-client and desktop-security-center alongside deeper changes to snapd and AppArmor available in the upcoming snapd 2.65. The first is a new prompting client (built in Flutter) that surfaces the prompt requests from the application via snapd. The second is our new Security Center:
In this release the Security Center is the home for managing your prompt rules, over time we will expand its functionality to cover additional security-related settings for your desktop such as encryption management and firewall control.
…
With prompting enabled, an application that has access to the home interface in its AppArmor profile will trigger a request to snapd to ask the user for more granular permissions at the moment of access:
As a result, users now have direct control over the specific directories and file paths an application has access to, as well its duration. The results of prompts are then stored in snapd so they can be queried and managed by the user via the Security Center.
Tldr; Ubuntu clones a macOS feature (from 2019) that actually makes sense.
Not that bad though
Yeah, all for security. I’ve been “complaining” about this for a while. :)
Looking at the video they posted, surely the act of navigating and selecting a location via the file save portal should implicitly give permission?
Iirc, that’s something Flatpak allows.
From the Discourse Blog:
The Linux desktop provides XDG Desktop Portals as a standardised way for applications to access resources that are outside of the sandbox. Applications that have been updated to use XDG Desktop Portals will continue to use them. Prompting is not intended to replace XDG Desktop Portals but to complement them by providing the desktop an alternative way to ask the user for permission. Either when an application has not been updated to use XDG Desktop Portals, or when it makes access requests not covered by XDG Desktop Portals.
Since prompting works at the syscall level, it does not require an application’s awareness or cooperation to work and extends the set of applications that can be run inside of a sandbox, allowing for a safer desktop. It is designed to enable desktop applications to take full advantage of snap packaging that might otherwise require classic confinement.
So this looks like it complements and not replaces the XDG Desktop Portals, especially for applications that have not implemented the Portals. It allows you to still run those applications in confinement while providing some more granular access controls.
XDG Desktop Portals as a standardised way for applications to access resources that are outside of the sandbox
It is designed to enable desktop applications to take full advantage of snap packaging
So all this only affects Snap apps, is that correct?
Yes, based on the diagrams on their blog, it looks like this only impacts Snaps.
I’m not exactly sure whether or not this is good, but my gut feeling is that this sounds like it will very quickly become very annoying permission hell.
macOS can be a bit of a permission hell at times, but I’ll take it over having less control over the privacy and security of my system
It seems like it would be useful for things like camera permissions and stuff, but it seems a little unnecessarily complicated for file access compared to just using a filechooser portal like flatpak does, then the user can just select specifically what they want when they want to without having to think about permissions.
Presumably its only opt-in to the application you want to use it with. If this new system was applied to all applications by default, yeah it could become a problem. The reason why the permission control in Android and Flatpak works is, because those applications and packages are designed and built with these limitations by default and the user should not need to modify the permissions. There are a few cases (in Flatpak) where you need to change the permission, which is annoying, especially if you don’t know. How worse will it be with applications that are not designed with these limitations in mind and force them with permissions taken away with this new tool?
Overall I don’t think it’s such a bad idea to have a technology on your hand to limit permissions and access, but it needs to be opt-in. In example this could be useful for AppImages, that are downloaded from the web and not managed by your operating system or a community like Flathub.
Ubuntu’s AppArmor? I thought that AppArmor is fully separate from Ubuntu, and just a Linux module + user space? https://gitlab.com/apparmor/apparmor
Thats why they said “Ubuntu’s AppArmor implementation”, as in how they configure and integrate it.
is that what they mean by that? I also know it reads: “Ubuntu’s AppArmor implementation". But I didn’t knew it need additional “implementation”. I can just run:
sudo aa-status. I still think it’s just a standalone module, and Ubuntu or Debian literately doesn’t need to implement anything extra afaik. Maybe only some configuration files at: /etc/apparmor.d (and most of these files are most likely also not coming from Ubuntu xD)Specific configuration is an implementation, as are hooks they may add to their own software to leverage features. Both Debian and Ubuntu also build their own profiles.
I see. Interesting. In my case AppArmor seems to be enabled by default under Linux Mint. As well as under my Ubuntu Server. I might need to look into this better, it looks like an important topic that many people overlooked.
It says for example “107 processes are in enforce mode”. But also… 4 profiles are in complain mode…
It’s probably something most people could learn a bit more about. On Red Hat or Fedora you don’t have to get too far out of vanilla before SELinux starts breaking things (oh, you wanted your custom systemd service to run that binary from that directory? Tough! Figure it out!), in comparison AppArmor on Ubuntu and Debian seems to get in the way a lot less. I’m not sure if that’s due to how it functions as a product or upfront work to configure it to be less intrusive.
That is very correct. SELinux is an alternative to AppArmor. But SELinux is much more secure but that comes with a cost. And that is the cost you just described. SELinux is much more advanced and gives you much more control.
Every time, I’m ready to jump the Ubuntu ship and go back to Debian or Mint, they announce something interesting; something I’d at least want to try.
Is this tied to Snap format? Or can this be used with any application you want and only require AppArmor? Flatpak or Android does permission control too and its a good idea to have. But those require the app to be created with these permissions in mind, whereas this new solution from Canonical can seemingly work with any application.
it seems like AppArmor isn’t from Ubuntu, so that is great news. So that feature alone it doesn’t require snap. But I’m now talking only about AppArmor.
But this whole ‘fine-grained access control blabalba’ does require Snap indeed…!
I wish other distro’s would implement this. It’s a very modern thing to do and really does make linux as a desktop feel more complete.
I’m fairly sure flatpaks are planned to have something like this and I am really looking forward to it
Flatpaks doing this would solve my last real problem with them
Agreed, and it is a tragedy that this requires snapd.
I hate snaps, so thanks but no thanks if this requires snapd.
