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

Vincas Dargis vindrg at gmail.com
Tue Feb 6 18:51:18 UTC 2018


On 2/5/18 11:06 PM, Jamie Strandboge wrote:
>> 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.


I do some strange things with $HOME with sysdig:

 > geteuid
< geteuid euid=1000(vincas)
 > openat dirfd=-100(ENETDOWN) name=/home/vincas 
flags=1059(O_DIRECTORY|O_EXCL|O_RDWR) mode=0600
< openat fd=6(<d>/home/vincas)
 > fstat fd=6(<d>/home/vincas)
< fstat res=0
 > ftruncate
< ftruncate
 > mmap addr=0 length=131072 prot=5(PROT_READ|PROT_EXEC) 
flags=1(MAP_SHARED) fd=6(<d>/home/vincas) offset=0
< mmap res=7FF29AA90000 vm_size=88956 vm_rss=15244 vm_swap=0
 > mmap addr=0 length=131072 prot=3(PROT_READ|PROT_WRITE) 
flags=1(MAP_SHARED) fd=6(<d>/home/vincas) offset=0
< mmap res=7FF29AA64000 vm_size=89084 vm_rss=15244 vm_swap=0
 > close fd=6(<d>/home/vincas)
< close res=0

mmap with PROT_EXEC.. on $HOME?

Anyway, do we _really_ want to allow mmap on writable files..?

I would, again, suggest to deny these with hope we would have a way to 
override denies in the future (John mentioned something in that regard) 
for some high performance 3D application really needs these NVIDIA 
optimizations to be available, maybe in 
`abstractions/nvidia-unsafe-optimizations` abstraction.




More information about the AppArmor mailing list