On 10/31/2017 06:56 PM, Christian Seiler wrote: > I don't know what the best short-term compromise is here, but in the > long term the only real solution is to somehow abstract this away from > applications to ensure that the application started in these cases is > actually what the user wanted. (I'm thinking towards something like > the 'portals' concept in Flatpak.) Because if the default policy does > not cover these kinds of customization needs out of the box at least a > lot of desktop users will simply revert AppArmor and complain about > it. Sadly I have so far been ignorant about Flatpak, which was probably a mistake. I think the abstractions I seek here is that the file is passed with its type to a different arbiter of defaults that is then responsible for opening the right program. And there needs to be a context transition in which the arbiter can then actually execute what it wants. At the same time it needs to be a very limited interface that does not allow customization. On the other hand Thunderbird parses the file associations by itself today and raises an application picker. This would again need to be isolated away[1]. I'm not sure if I missed some kind of alert tool like the selinux troubleshooting bits, but in my case it just silently failed: you click on links and nothing happens. I suppose such failures that the kind of failures we'd want to avoid because users just keep being confused about how to re-mediate the issue and then turn off security features. (Not unsimilar to how people deal with SELinux, except that some might pipe the denials through audit2allow?) Kind regards and thanks Philipp Kern [1] And even then I know that a bunch of uncommon file types raise a bunch of red flags in terms of auto-detection and exploitation. CVE-2017-1000083 comes to mind. Which at least could have been mitigated by AppArmor on evince, in theory. Except that evince also needs to be able to handle links in some fashion and back to square one.
Attachment:
signature.asc
Description: OpenPGP digital signature