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.


--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to