Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertag -1 +modify-profile
On Mon, 16 Jul 2018 16:58:24 +0200 Carsten Schoenert <c.schoen...@t-online.de>
wrote:
Hello Vincas,
may I point you to this report?
Sure!
On Mon, Jul 16, 2018 at 12:45:49PM +0100, Nuno Oliveira wrote:
> Actually, better make it:
>
> ### Extra:
> /sys/devices/system/memory/block_size_bytes r,
> owner @{HOME}/.nv/.gl* rwm,
> owner /tmp/.gl* rwm,
Now that "/sys/devices/system/memory/block_size_bytes r," needs simple backport, as is is already
available in more recent AppArmor [0]. I have forgot this issue as I run Thunderbird on Intel
graphics (I have no denies)...
Let's talk about these "rwm" then. This is a kinda known issue.
NVIDIA drivers tries to mmap() for execution some sort of optimization-related generated files from
these paths OP mentioned [1].
I have started a thread in a upstream AppArmor mailing list [2] where we have discussed how could we
deal with it , because "blindly" mmap()'ing files for execution from user-writable directories is
not.. "fun".
My "proper" fix plan is to use new AppArmor "conditionals" feature to allow profile to select if it
wants to enable some (in this case maybe less secure) feature form a abstraction or not.
For example, in our case it would look like this:
usr.bin.thunderbird:
```
#include <tunables/global>
...
$nvidia_enable_optimizations = false
...
profile thunderbird ... {
...
#include <abstractions/nvidia> # it will now silently deny optimizations
...
}
```
If we declare that we do not want NVIDIA-specific possibly-unsafe optimizations (like mmap'ing()
user-writable files from /tmp or somewhere in $HOME), abstraction will silently deny all relevant
access.
I believe (most of) you will agree that Thunderbird is not high-performance-3D-grapchics-client that
would need to get most of powerful NVIDIA graphics accelerator, and we would be more happy with
better security instead, so I would go to disabling (denying) these optimizations in Thuderbird
profile. Meanwhile, Firefox profile might have these enabled, as this browser are used for WebGL
applications that might actually have benefit from these optimizations.
The catch is that this "conditionals" feature would be only available since AppArmor 2.13 (I believe
better tooling support might come later) in Buster, and since Thunderbird profile ships in older
releases, I guess I could just "simply" backport deny rules directly...
Carsten, or maybe we could somehow maintain "two versions" of usr.bin.thunderbird without having too
much of burden for you? Like, for Buster we would have profile variant with:
```
$nvidia_enable_optimizations = false
```
meanwhile, for Stretch and older:
```
deny @{HOME}/.nv/.gl* rwm,
deny /tmp/.gl* rwm,
```
I am not sure how much maintainership is made harder by having jessie/stretch/buster branches
differ. Although backporting rules "forever" (until Stretch is no longer supported, and Buster might
have AppArmor v3 with proper versioning tools) also does not help a lot, as we miss all these new
features. So that's the dilemma.
[0]
https://gitlab.com/apparmor/apparmor/commit/0d0a1960778588a3f390a4a07e9b0e0ce08336ad
[1]
https://devtalk.nvidia.com/default/topic/1029338/linux/libgl-tries-to-create-home-user-nv-directory-after-failing-to-mmap-tmp-gl-for-execution/post/5235879/#5235879
[2] https://lists.ubuntu.com/archives/apparmor/2018-February/thread.html#11457
