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
>
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
