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

[Vincas Dargis]

On 1/25/18 9:31 AM, John Johansen wrote:
> 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

Even if environment scrubbing would work, should it still allow execute xdg-open _anything_ (like that example) directly?

My idea is to limit what these kind of helpers could execute, regardless if environment is scrubbed or not. I am 
focusing on that example where Dragon should be allowed to launch only browsers and email clients via xdg-helper helper.

Without that limitation, if user has ".sh" associated with "gnome-terminal -x %s" for some convenience reason, Dragon 
would launch xdg-open that would launch an interpreter for the attacker.

>> 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

I am kinda imaginary adding emphasis on *this*" :) . Do you have something specific in mind, what could be other 
situations that I should be aware of (I really don't have that much experience in all of this) ?

>> 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

So, if <abstraction/ubuntu-email> would have[0] `/usr/bin/thunderbird` rule, and it is actually a bash script, we are 
kinda.. screwed?

Does my xdg_open child profile makes situation worse? I imagine if that child profile uses abstractions, and these 
abstractions also use sanitized_helper, I see improvement against `xdg-open -> sanitized_helper`, or I am wrong / 
missing something?

... epiphany happens ...

Oh, I see that xdg-open _itself_ is a shell script, maybe that's the problem here?


>> 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

Maybe you mean like that _capital_ C in "Cx" does not help here enough?

Thanks!

[0] P.S. it does not. It's a missing rule I guess, as xdg-open runs kde-open5 that actually runs /usr/bin/thunderbird` 
in the end, not that /usr/lib/thunderbird... we currently have:

$ sudo sysdig "(proc.name=xdg-open or proc.name=kde-open5) and evt.type=execve"

$ xdg-open "mailto:foo at example.com"

Sysdig output:

69924 19:56:04.319244632 0 xdg-open (7664) < execve res=0 exe=/bin/sh args=/usr/bin/xdg-open.mailto:foo at example.com. 
tid=7664(xdg-open) pid=7664(xdg-open) ptid=2446(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=35 vm_size=440 vm_rss=4 
vm_swap=0 comm=xdg-open cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/.devices=/user.slice.freezer=/.net_cls=... 
env=GS_LIB=/home/vincas/.fonts.KDE_FULL_SESSION=true.LANG=lt_LT.UTF-8.PROFILEHOME... tty=34818

70049 19:56:04.321695532 0 xdg-open (7665) > execve filename=/usr/bin/kde-open5

70054 19:56:04.321926012 4 kde-open5 (7665) < execve res=0 exe=kde-open5 args=mailto:foo at example.com. 
tid=7665(kde-open5) pid=7665(kde-open5) ptid=7664(xdg-open) cwd= fdlimit=1024 pgft_maj=0 pgft_min=21 vm_size=344 
vm_rss=4 vm_swap=0 comm=kde-open5 
cgroups=cpuset=/.cpu=/.cpuacct=/.io=/.memory=/.devices=/user.slice.freezer=/.net_cls=... 
env=KDE_FULL_SESSION=true.PROFILEHOME=.GS_LIB=/home/vincas/.fonts.HISTTIMEFORMAT=... tty=34818

107801 19:56:04.410087956 1 kde-open5 (7668) > execve filename=/usr/bin/thunderbird