You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose Policy A declares and uses metadata M. Policy B can import A and then use M in its own rules. A common use-case of this functionality is to allow B to make rules that are based on program/metadata state that is being monitored/maintained by A.
Disallow building policy using metadata M without the policy "owning" M
However, policy B can currently be built without policy A. In other words it can be built standalone; as something other than a composite using policy A. In this case, M is probably not a reasonable thing to be using, since the "owner" of M is not maintaining it.
I suggest that any policy using metadata M should NOT be compiled unless the policy declaring metadata M will also be running.
How much access should policies have?
We may want to enforce that policy B has read-only access to M. This would avoid surprising things happening to the policy writer of policy A in which some other module modified his metadata outside of his rules. (Maybe things are already set up this way?)
Order of operations
Suppose policy A has a rule: allGrp(code == [+X] -> env = [+M]) and policy B has a rule: allGrp(env == [+M] -> env = [+Y]). Depending on the ordering of policy evaluation, this could mean that env cannot have M without also having Y. Alternatively, it could be that env has only M for one instruction before picking up Y from the rule in policy B.
This should be defined for the policy writer, and the definition should be implemented in the policy-tool. (Maybe it already is?)
The text was updated successfully, but these errors were encountered:
Suppose Policy
A
declares and uses metadataM
. PolicyB
canimport A
and then useM
in its own rules. A common use-case of this functionality is to allowB
to make rules that are based on program/metadata state that is being monitored/maintained byA
.Disallow building policy using metadata
M
without the policy "owning"M
However, policy
B
can currently be built without policyA
. In other words it can be built standalone; as something other than a composite using policyA
. In this case,M
is probably not a reasonable thing to be using, since the "owner" ofM
is not maintaining it.I suggest that any policy using metadata
M
should NOT be compiled unless the policy declaring metadataM
will also be running.How much access should policies have?
We may want to enforce that policy
B
has read-only access toM
. This would avoid surprising things happening to the policy writer of policyA
in which some other module modified his metadata outside of his rules. (Maybe things are already set up this way?)Order of operations
Suppose policy
A
has a rule:allGrp(code == [+X] -> env = [+M])
and policyB
has a rule:allGrp(env == [+M] -> env = [+Y])
. Depending on the ordering of policy evaluation, this could mean thatenv
cannot haveM
without also havingY
. Alternatively, it could be thatenv
has onlyM
for one instruction before picking upY
from the rule in policyB
.This should be defined for the policy writer, and the definition should be implemented in the policy-tool. (Maybe it already is?)
The text was updated successfully, but these errors were encountered: