[apparmor] Note: NVIDIA drivers are mapping user-writable files by default

[Vincas Dargis]

Hi,

I would like to share some info about particular DENIED messages that 
happen on the machines with NVIDIA graphics hardware and proprietary 
divers. This does not happen with integrated Intel chips.

You might have seen these kind of denies:

```
type=AVC msg=audit(1517738575.272:418): apparmor="DENIED" 
operation="open" profile="/usr/bin/glxgears" 
name="/home/vincas/#12976887" pid=21444 comm="glxgears" 
requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

type=AVC msg=audit(1517738575.272:419): apparmor="DENIED" 
operation="mknod" profile="/usr/bin/glxgears" 
name="/home/vincas/.glvndMxWhdd" pid=21444 comm="glxgears" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

type=AVC msg=audit(1517738575.272:420): apparmor="DENIED" 
operation="open" profile="/usr/bin/glxgears" name="/tmp/#2492715" 
pid=21444 comm="glxgears" requested_mask="wr" denied_mask="wr" 
fsuid=1000 ouid=1000

type=AVC msg=audit(1517738575.272:421): apparmor="DENIED" 
operation="mknod" profile="/usr/bin/glxgears" name="/tmp/.glvndFEnPtV" 
pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 
ouid=1000

type=AVC msg=audit(1517738575.316:422): apparmor="DENIED" 
operation="mknod" profile="/usr/bin/glxgears" name="/tmp/.gls5YBRD" 
pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 
ouid=1000


type=AVC msg=audit(1517738575.316:423): apparmor="DENIED" 
operation="mkdir" profile="/usr/bin/glxgears" name="/home/vincas.nv/" 
pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 
ouid=1000

```

To make this more readable, extracted paths of interest:

/home/vincas/#12976887

/home/vincas/.glvndMxWhdd (.glvnd*)

/tmp/#2492715

/tmp/.gls5YBRD

/home/vincas.nv/

So far it's only denies for rw/c permissions. After allowing to write to 
theses paths with these rules:

```
owner /tmp/#[0-9]* rw,
owner /tmp/.gl* rw,
owner @{HOME}/#[0-9]* rw,
```

new denies appears for file_mmap:

```
type=AVC msg=audit(1517739204.123:468): apparmor="DENIED" 
operation="file_mmap" profile="/usr/bin/glxgears" 
name="/home/vincas/#12976887" pid=23170 comm="glxgears" 
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
```

```
type=AVC msg=audit(1517739204.163:470): apparmor="DENIED" 
operation="file_mmap" profile="/usr/bin/glxgears" name="/tmp/.glhWbOWH" 
pid=23170 comm="glxgears" requested_mask="m" denied_mask="m" fsuid=1000 
ouid=1000
```

The peculiar path `/home/vincas.nv/` suggested a bug, and Debian bug 
report exists for that [0].

After some digging, it appears that:

1. NVIDIA's libGL tries to mmap() some temporary files for execution.

2. Additionally, if it fails to do that in the primary locations, it 
tries to create $USER.nv directory and try that there.

For issue #2, it's a confirmed NVIDIA path concatenation bug, and 
probably be fixed and probably can be more or less ignored.

For issue #1, it seems that is not a bug, but works as designed, for 
implementing some sort of optimization, that can be disabled with 
__GL_WRITE_TEXT_SECTION=0 env. var.

Both #1 and #2 are confirmed in NVIDIA development forums [1].

Now the question for AppArmor side of affairs, I see two questions:

Q1: What's the deal with these /home/vincas/#12976887 paths? Sysdig 
fails to show events for that kind of paths (or I fail to catch them). 
Is is some sort of failure from Linux/AppArmor kernel side? Some 
propiertary-binany-driver-blob magic? I does look like same attempts as 
with .gl* mentioned files above.

Q2. What could be done with these deny messages in AppArmor policies?

For Q2, I'm suggesting to add rules in `abstractions/nvidia` to deny all 
mmaps, _maybe_ allow to write @{HOME}/.glvnd*, and probably deny 
completely all these seems-like-bogus #[0-9] writes too.

This might produce some sort of performance degradation (I do not have 
any numbers) if these mmaps() are denied for optimizations, but I doubt 
we have a lot of high performance 3D users currently... At the time when 
this could be discovered as regression for some applications, maybe 
AppArmor (hint hint) will have way to override denies in policy file for 
specific cases.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888028
[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