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

[Jamie Strandboge]

On Tue, 2018-02-06 at 20:51 +0200, Vincas Dargis wrote:
> 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?
> 
I don't use sysdig, but this seems consistent with my previous reply,
when you pass an fd to a dir to mmap with MAP_SHARED, it does the
anonymous shared memory in that dir. Again, more investigation is
needed, but if nvidia is passing HOME as that fd, this is what I would
expect to see.

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

Not usually, but in the case of actual shared memory files, there isn't
another choice atm. Some day we'll mediate shared memory with non-file
rules[1].

> 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.

I'm not sure this is the best way to handle this. Remember, explicit
deny rules are evaluated after deny rules so adding explicit deny rules
for these files means that an abstraction like nvidia-unsafe-
optimizations wouldn't be able to undo the deny (I guess this is what
you meant by overriding denies).

Furthermore, as a user, if I had an nvidia card I would expect that the
nvidia abstraction would allow 3D acceleration to work and it sounds
like nvidia changed the way their shared memory works (again, I don't
have an nvidia system and basing this on the fact that these denials
are only showing up now). I would instead suggest that *if* we wanted
to split these accesses, we do something more like:

 * abstractions/nvidia-strict: all the safe accesses
 * abstractions/nvidia: #include nvidia-strict plus less desirable 
   accesses

In this manner, profiles continue to work with new nvidia accesses, but
 profilers can choose to do something more strict if they desire.

[1]https://bugs.launchpad.net/apparmor/+bug/1370218

-- 
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/20180206/d41e8e08/attachment.sig>