3 ms·

Things like apparmor can work well because the author or distributor of a package knows that it shouldn't ever do a particular thing, so if it attempts to, that

Things like apparmor can work well because the author or distributor of a package knows that it shouldn't ever do a particular thing, so if it attempts to, that is a bug and it should be refused. The user shouldn't even have to be aware that this is the case because the program shouldn't even attempt to do the thing the author/distributor asserted it will never do. The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. If you e.g. have an office suite and don't permit full home directory access, users will bail out because they cannot open files in their random folder structure. If you permit full home access, it could be exploited to exfiltrate data, write malicious files, etc. macOS solves this by using a privileged service for Open/Save dialog boxes. If you ask for an open dialog in a sandboxed application, it is handled by this privileged service, which makes the file available in the application's sandbox. It is quite elegant, because it does not require the user to follow any additional steps (it works as any other file dialog), but restricts an application to its own sandbox. Flatpak also follows this approach with its portal mechanism (which is unfortunately not supported by every application yet).

zrm 7y ago
> The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. It works fine. Its purpose is to solve a different problem than this. > macOS solves this by using a privileged service for Open/Save dialog boxes. There are circumstances where this can be useful, and it would be fine to implement this on Linux for applications where it's appropriate, but it doesn't work as a universal rule. For example, suppose I have a music player app, I choose open, I get the dialog and choose a playlist. The playlist file is just a list of paths to music files which were never selected in the dialog. The app still needs to open all the music files. And the same thing for office documents with links to images, source code project files etc. And what about background services? If I install an app to make regular backups of my home directory then it needs access to the whole thing, and not just once. Likewise anything that does indexing, malware scanning etc. So it's still really the same thing. You have an app that asserts it never needs access to files outside the open dialog and then it can be restricted to just that, but other apps need to do different things. You need somebody to identify which apps can do without certain capabilities, the average user is not equipped for that, so it falls to the author or the packager.

zrm 7y ago

> The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. It works fine. Its purpose is to solve a different problem than this. > macOS solves this by using a privileged service for Open/Save dialog boxes. There are circumstances where this can be useful, and it would be fine to implement this on Linux for applications where it's appropriate, but it doesn't work as a universal rule. For example, suppose I have a music player app, I choose open, I get the dialog and choose a playlist. The playlist file is just a list of paths to music files which were never selected in the dialog. The app still needs to open all the music files. And the same thing for office documents with links to images, source code project files etc. And what about background services? If I install an app to make regular backups of my home directory then it needs access to the whole thing, and not just once. Likewise anything that does indexing, malware scanning etc. So it's still really the same thing. You have an app that asserts it never needs access to files outside the open dialog and then it can be restricted to just that, but other apps need to do different things. You need somebody to identify which apps can do without certain capabilities, the average user is not equipped for that, so it falls to the author or the packager.