On 01/25/2018 10:15 AM, Vincas Dargis wrote:
> 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?
it would depend on how you structure your policy, you certainly don't have to
allow it
>
> 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.
>
sure, and that should basically eliminate the problem that sanitized_helper is
trying to deal with
> 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.
>
yep
>>> 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) ?
>
So you have to understand my reply was in the context of not liking sanitized
helpers, they unfortunately still have a role. As long as we are talking
confinement on the targets we should be fine. The sanitized helpers were
specifically for going from a confined to a "lightly" confined or unconfined
situation. To quote abstractions/ubuntu-helpers
# Lenient profile that is intended to be used when 'Ux' is desired but
# does not provide enough environment sanitizing. This effectively is an
# open profile that blacklists certain known dangerous files and also
# does not allow any capabilities. For example, it will not allow 'm' on files
# owned be the user invoking the program. While this provides some additional
# protection, please use with care as applications running under this profile
# are effectively running without any AppArmor protection. Use this profile
# only if the process absolutely must be run (effectively) unconfined.
#
# Usage:
# Because this abstraction defines the sanitized_helper profile, it must only
# be #included once. Therefore this abstraction should typically not be
# included in other abstractions so as to avoid parser errors regarding
# multiple definitions.
#
# Limitations:
# 1. This does not work for root owned processes, because of the way we use
# owner matching in the sanitized helper. We could do a better job with
# this to support root, but it would make the policy harder to understand
# and going unconfined as root is not desirable any way.
#
# 2. For this sanitized_helper to work, the program running in the sanitized
# environment must open symlinks directly in order for AppArmor to mediate
# it. This is confirmed to work with:
# - compiled code which can load shared libraries
# - python imports
# It is known not to work with:
# - perl includes
# 3. Sanitizing ruby and java
#
# Use at your own risk. This profile was developed as an interim workaround for
# LP: #851986 until AppArmor utilizes proper environment filtering.
>>> 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?
>
no, its only if that bash script consults the environment variables to
determine what to execute and that decision can be used to change the
confinement to something looser than would be allowed.
Lets say I have a script that responds to $HELPER
the profile
/bin/foo px,
/bin/bar px,
is fine, because even if $HELPER is set by an attack to something else
confinement transition is limited to those 2
now if I have a profile
/bin/foo px,
/bin/bar px,
/** ux,
allowing an attacker to control $HELPER could be used to unconfined state
> Does my xdg_open child profile makes situation worse?
no
> 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?
>
>
I think I have covered above
>>> 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?
>
correct the env var scrubbing is done by setting a flag in the kernel that the
elf loader/linker responds to scrubbing certain dangerous environment
variables. But script interpreters have their own dangerous set beyond what the
elf loader scrubs, we plan to make it so you can specify additional scrubbing
in policy.
> 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
