[apparmor] RFC: handling xdg-open and similar helpers

John Johansen john.johansen at canonical.com
Thu Jan 25 07:31:38 UTC 2018


On 01/21/2018 08:27 AM, Vincas Dargis wrote:
> Hi,
> 
> I have some WIP AppArmor profiles for applications that uses `xdg-open` to open link or attachment. For example, `usr.bin.dragon` profile (KDE multimedia player) has this line [0]:
> 
> ```
> /usr/bin/xdg-open Cx -> sanitized_helper,
> ```
> 
> Aaand.. I don't like it.
> 
you are not the only one. It was meant as a temporary solution. However the real solution or better control over environment scrubbing was deprioritized. But its important and needs to be finished off once the current delta is upstream

> Dragon only needs to open browser (for clicking "Help -> Report a bug") and email client (when clicking translator's email button in About dialog), and that's it. So I figure that a more secure approach (by limiting allowed target applications to open something with) could be implemented by using abstraction in a child profile. Consider this alternative:
> 
> ```
> /usr/bin/xdg-open Cx -> xdg_open,
> 
> profile xdg_open {
>     #include <abstractions/xdg-open> # or should it be xdg-open-common ?
> 
>     # Dragon only needs to open http: and mailto: links
>     #include <abstractions/ubuntu-browsers>
>     #include <abstractions/ubuntu-email>
> }
> ```
> 
sure this will work for this situation

> Another applications, like Skype, might need much more abstractions included to open various attachement files for example.
> 
> I know (but only know, now actual experience) that there are `exo-open` relevant for XFCE desktop, that also could have it's own abstraction prepared too.
> 
> If this approach seems sensible for AppArmor team, I could start working on this.
> 
I am not opposed where it makes sense but we have to be careful when it comes to transitions with applications that use an interpreter (bash, python, perl java), because currently we can't sanitize Env vars that can affect the interpreters behavior. As long as the transition is to a tight confinement we are okay, but if its to unconfined or a loose generic interpreter profile env vars become away for the attacker to control the child


> Or maybe there are, or going to be implemented, some other alternatives? Maybe upcoming delegation could offer different approach?
> 
delegation could help some but we really need to finish with the better control over env var scrubbing, relying on the secure exec flag in glibc isn't enough in some cases

> Thanks in advance for your input!
> 
> [0] https://gitlab.com/Talkless/apparmor-profiles/blob/33dd81adaf2638e7a7076f2ecb07aa80033bd7dd/ubuntu/18.04/usr.bin.dragon#L26
> 




More information about the AppArmor mailing list