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:[email protected]";
Sysdig output:
69924 19:56:04.319244632 0 xdg-open (7664) < execve res=0 exe=/bin/sh args=/usr/bin/xdg-open.mailto:[email protected].
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:[email protected].
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
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
