On 11/28/19 7:53 AM, Richard Haines wrote:
I'll change this (I try to avoid interfaces in tests as you need to lookup what they really contain and it may be more than you want, plus just plain allow rules are much clearer (but that's just me))
I'd agree if the interface is a poor match / overly broad but I think in this case it works well. I am sympathetic to the view that refpolicy interfaces are harder to use than raw policy rules (hence the almost complete lack of interfaces aside from common macros in the Android policy), but the one advantage they should carry is greater portability across refpolicy versions since they should automatically pick up changes in the base policy (e.g. if a type is renamed or split or coalesced, if a new permission besides the one being tested is introduced and needed for the abstract operation, etc). And if/when we transition refpolicy to a truly higher level policy language on top of CIL, then I would anticipate them providing greater benefits as first class abstractions rather than mere m4 macros. But I guess only time will tell...
