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

[John Johansen]

On 02/16/2018 06:44 AM, Vincas Dargis wrote:
> On 2/11/18 11:38 PM, John Johansen wrote:
>> On 02/11/2018 02:42 AM, Vincas Dargis wrote:
>>> So to wrap up, plan would be:
>>>
>>> 1. Move `abstactions/nvidia` content into `nvidia-strict`. `nvidia-strict` should have comment that it does not provide some NVIDIA optimizations and some `deny` rules are recommended to be added manually. Else, suggest to use `nvidia` if really needed.
>>>
>>> 2. Create new `abstractions/nvidia` that includes `nvidia-strict`. Add a _big_ warning documenting that it provides NVIDIA optimization that could potentially reduce security, suggest to use `nvidia-strict` for non-performance-critical applications instead.
>>>
>>> In the future:
>>>
>>> 3. Deny these optimizations in `nvidia-strict` by default, add overrides into `nvidia` abstraction when that's becomes possible.
>>>
>>> ACK?
>>>
>>> Any more alternatives?
>>>
>>> [0] https://gitlab.com/apparmor/apparmor/wikis/home#description
>>>
>>
>> I'm not against the plan, I do worry about being too strict causing problems, and I think the tunable + conditional might (I am not sure yet) a better way to go
> 
> Could you give example how this tunable + conditional would look like?
> 
see below

> Would this be per-machine or per policy decision (probably the latter)?
> 
it could be setup either way, it would depend on how you setup the conditionals and tunable variable. With that said the tools (logprof,genprof,...) don't currently get along with conditionals.

there are a couple ways to set this up, and there would certainly need to be some documentation/comments in the nvidia include as to how to enabled/disable.

Assuming that strict is optional (you could always flip the logic with a negation and rename the var) Basically it would be something like

  $ cat abstractions/nvidia
  # set $nvidia_strict to add
  if defined $nvidia_strict {
    ...
  }
  ...

  $ cat profile
  include <global/tunnables>

  #opt in to strict nvidia mediation
  $nvidia_strict=true

  profile example {
     include <abstractions/nvidia>

     ...
  }


If you wanted to do it globally
  $ cat global/tunable
  # change value to true to enable nvidia strict enforcement
  $nvidia_strict=false
  ...

and your nvidia include logic would drop the "defined" bit

  $ cat abstractions/nvidia
  # set $nvidia_strict to add
  if $nvidia_strict {
    ...
  }
  ...

  

> 
> Now for the Jamie suggestion:
> 
> On 2/12/18 7:40 PM, Jamie Strandboge wrote:
>> This is what I initially recommended but based on your later
>> investigations I later recommended something different. I now suggest
>> simply:
>>
>> 1. update the nvidia abstraction to have comment that it does not
>> provide some NVIDIA optimizations and to either add `deny` rules
>> manually to silence the denials or add allow rules if want the
>> optimizations. Both sets of rules would be commented out in the nvidia
>> abstraction under the aforementioned comment.
>>
> 
> Sorry, I misunderstood your suggestion. So it's basically approach using documentation only?
> 
> There could be another approach without "deny and then override" that John didn't show affection for:
> 
> 1. <abstractons/nvidia> Left unchanged, except maybe adding info about missing permissions for possibly unsafe optimization, hint how to fix that
> 
> 2.a new <abstractions/nvidia-with-optimizations> abstraction that includes <abstractions/nvidia> and allows rules for optimizations.
> 
> 2.b new <abstractions/nvidia-without-optimizations> abstraction that includes <abstractions/nvidia> and denies optmiziations.
> 
> usr.bin.thunderbird could be updated to change "nvidia" into "nvidia-without-optimizations" and "usr.lib.ioquake3.ioquake3" could be updated to include "nvidia-with-optimizations" instead.
> 
> Now I'm still interested in that "tunable + conditiona"l, though I would like to see how that would work. It smells like something more modern and cleaner approach? :)