Hi there,
On 10/31/2017 01:46 PM, Philipp Kern wrote:
>>> [2] e.g.
>>> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>>> apparmor="DENIED" operation="exec" profile="thunderbird"
>>> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>>> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
>
> Filed as #880424[0]. I think there is a deeper question here as to how
> to handle the browser abstraction for AppArmor in general.
Isn't this a really generic problem for any AppArmor/SELinux-like LSM?
Because this isn't just restricted to links, this is restricted to any
kind of file association (links are handled like file associations with
the MIME type x-scheme-handler/$PROTOCOL in the XDG specs).
Because in the end you have the following conflicting requirements:
- On the one hand, you want the user to be able to open arbitrary
files and links from many programs (especially e.g. email programs),
for example opening PDF attachments with your favorite PDF reader
or external links in your browser.
This means that the email program must be able to execute arbitrary
executables, because the user may have assigned arbitrary
executables (for example also wrapper scripts in their home
directory) to different file associations.
- The user might also want to open a specific file with another
program that is also associated with the file but not the default.
For example, JPEG attachments might most commonly be opened by
the favorite image viewer, but sometimes users may want to open
the JPEG file in an image editor such as GIMP, and many programs
offer the user a choice to choose between the installed programs
that are associated with the type.
- On the other hand one of the key features of AppArmor is to mitigate
exploits so that an attacker can't just get the program to call the
syscall execve("/bin/sh", {"/bin/sh", "-c", "wget payload | sh"});
I think this is a more general problem. It appears to me that there are
currently two possibilities:
- Either one allows the execution of arbitrary executables by all
desktop applications (because we don't know in advance what file
types will be associated with what program, and the user may have
their own wrapper scripts) - but that leaves a gaping hole in the
possible mitigations AppArmor may provide.
- Or one whitelists certain applications. This will have the
unfortunate side-effect that any time the user installs a piece of
software that isn't on that whitelist (or wants to use their own
wrapper script) it won't work (because of AppArmor) - and
unfortunately many users will then simply resort to disabling
AppArmor in that case instead of actually creating a locally
adapted policy. (Yes, sysadmins might not, but simple desktop
users will - I know way too many people who simply don't even want
to use group ownership and instead are happy to just do a
chmod 0777 - and groups are mentally a lot simpler than AppArmor.)
I don't know what the best short-term compromise is here, but in the
long term the only real solution is to somehow abstract this away from
applications to ensure that the application started in these cases is
actually what the user wanted. (I'm thinking towards something like
the 'portals' concept in Flatpak.) Because if the default policy does
not cover these kinds of customization needs out of the box at least a
lot of desktop users will simply revert AppArmor and complain about
it.
Regards,
Christian
