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

[John Johansen]

On 02/16/2018 12:09 PM, Vincas Dargis wrote:
> On 2/16/18 9:33 PM, John Johansen wrote:
>> On 02/16/2018 06:44 AM, Vincas Dargis wrote:
>>> 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 {
>>      ...
>>    }
>>    ...
> 
> OK so I see two mechanisms, "if defined $var" and "if $var". I guess we could avoid "forgot to read documentation" issue with this construct (not sure how negation would look like, just a guess):
> 

yeah basically, if you know the var is going to be defined you can get away with an if $var, but if you are going to allow the profile to define then the if defined is needed because the parser will throw an error about on undefined var being used other wise

and your guess on inverting the logic is corrent

  if not $foo {

you can also do

  if not defined $foo {


> $ cat abstractions/nvidia
> 
> if defined $nvidia_strict {
>   if not $nvidia_strict {
>     # allow possibly unsafe NVIDIA optimizations, see <link>.
>     owner @{HOME}/#[0-9]* rwm,
>     owner @{HOME}/.glvnd[0-9]* rwm,
>     owner /tmp/.gl[0-9]* rwm,
>     owner /tmp/#[0-9]* rwm,
>     ...
>   }
> } else {
>   error $nvidia_strict is not defined, see abstractions/nvidia for more info
> }
> 
> If we could have parsing-time error/warning/assert statements, that would force policy writer to explicitly decide on turning on or off specific options, probably unavoidably reading comments on what do they mean, etc.

yes parse time error, warning and asserts so policy can provide messages are on the todo list they just haven't been a high priority because conditionals have not been really used. That is about to change because policy versioning requires them