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

[Vincas Dargis]

On 2/6/18 9:25 PM, Jamie Strandboge wrote:
>> 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].

There is a choice to deny it. Since these... paths (not originally 
intended to be a "physical file", except to these .gl*) are requested to 
be mmap'ed for execution, some _real_ file named @{HOME}/#3141528 or 
/tmp/.glMy1337Exploit could be loaded to enhance attack further. Or mine 
Monero or smth. Or scan Thunderbird's memory for passwords.

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

I've meant a new feature (we don't currently have) to override a `deny`, 
like a higher priority level. JJ was talking about that possibility in 
the future, in IRC I believe. If that get's designed I guess.

Maybe having something like `override allow @{HOME}/#[0-8]* rwm` would 
override that default `deny @{HOME}/#[0-8]* rwm` in 
`abstractions/nvidia`, for some exceptional cases, like in Blender 
application where real time 3D graphics performance is _very_ important 
(if it would ever have AppArmor profile.. but that's just an example).

I'm betting on this because it doesn't seem we have a lot of 
graphic-intensive applications with AppArmor profile that might feel a 
hit due to disabled optional NVIDIA optimizations.

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

3D acceleration works fine with denies. It is only a additional 
optimization NVIDIA have implemented. It is even documented that it does 
not work on systems like SELinux and GRSecurity.

 From "Disabling executable memory optimizations" [0]:

quote

By default, the NVIDIA driver will attempt to use optimizations which 
rely on being able to write to executable memory. This may cause 
problems in certain system configurations (e.g., on SELinux when the 
"allow_execmem" boolean is disabled or "deny_execmem" boolean is 
enabled, and on grsecurity kernels configured with CONFIG_PAX_MPROTECT). 
When possible, the driver will attempt to detect when it is running on 
an unsupported configuration and disable these optimizations 
automatically. If the __GL_WRITE_TEXT_SECTION environment variable is 
set to 0, the driver will unconditionally disable these optimizations.

end quote.

So, if they disable them on SELinux and/or grsecurity kernels, we could 
disable it by ourselves for AppArmor cases. Again, 3D acceleration works 
fine with these denies (I use home-grew Wine and Steam profiles without 
allowing these).


>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.
So if profile includes `<abstractions/nvidia-strict>`, they would have 
to add these
`deny @{HOME}/#[0-8]* rwm`,
`deny /tmp/.gl* rwm`
manually, in addition to the include?

If non-strict `abstractions/nvidia` include is left where it is now, 
that means in current state, Thunderbird, Firefox, Totem, and now I see 
Libreofice (running with `optirun`, to enabled discrete NVIDIA card, I 
see deny for nvidia-specific /usr/bin/nvidia-modrpobe, so include is 
needed there too) will have their security downgraded by default, and 
these does not look like graphic intensive apps. Meanwhile, updating 
these profiles would be too much a fuzz for a _optional_ NVIDIA 
optimizations, IMHO. While for security, I'm fuzzing here to defend :) .


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


[0] 
https://download.nvidia.com/XFree86/Linux-x86_64/390.25/README/openglenvvariables.html#disableexecmem