[apparmor] Note: NVIDIA drivers are mapping user-writable files by default
Vincas Dargis
vindrg at gmail.com
Fri Feb 16 20:09:04 UTC 2018
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):
$ 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.
More information about the AppArmor
mailing list