[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