Harry Ciao wrote:
Joshua Brindle 写道:
Christopher J. PeBenito wrote:
<snip>>
Hi Joshua,
Honestly speaking I have become kinda confused. If tunable_policy()
remains as if-else conditionals then what Chris has wanted is to expand
all RBAC rules into cond_rule_def aside from just AVRULE_AV and
AVRULE_TYPE rules.
However, if tunable_policy() is to be implemented as a block, then
what's the major difference between such "tunable block " and the blocks
already created by optional_block()? The optional_block() already
supports the else-branch, and only one of the two branches would take
effect, also if its external requirement won't be satisfied, the whole
block would not be enabled and skipped over during expansion, which
sounds to me like a tunable which just has the if-branch and defaults to
false.
Yes, it is close. We thought about making a tunable symbol and putting
it in the require section of a block. Unfortunately it doesn't give us
the expressions that conditionals do ( foo || bar ) so it still isn't
ideal. Additionally you can't declare things in the else branch. We
didn't know how to deal with this case:
optional {
requires { type a; }
type b;
...
} else {
requires { type c; }
type d;
}
optional {
requires { type b; }
type c;
} else {
requires { type d; }
type b;
}
So we just punted on allowing declarations in the else block so Chris
uses them very rarely.
Anyway, it's good to know how tunable is handled in CIL, I would have
better understanding once I get to know more about it.
There was just a release of the compiler, take a look :)
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
