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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
