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

[Jamie Strandboge]

On Sun, 2018-02-04 at 13:16 +0200, Vincas Dargis wrote:
> 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.

This is likely how the nvidia driver is using anonymous shared memory.
If that is what it is doing (you could use strace to see how it is
calling mmap and what it is passing to it). If it is using anonymous
shared memory, then the #12976887 file doesn't actually exist on the
filesystem and is not accessible to other (non-child) processes. I
don't know what the ~/.gl* accesses are about, but would also guess it
has to do with shared memory, but in this case with actual files on the
system.

> 
> 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.
> 
You probably would need:

  owner @{HOME}/\#[0-9]* mrw,
  owner @{HOME}/.gl* mrw,

with some investigation with strace to justify the above, I suspect we
would want to add the above to the nvidia abstraction.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180205/5140e9bb/attachment.sig>