[apparmor] conditional rule syntax

[Jamie Strandboge]

On Sat, 2012-01-28 at 10:07 -0800, John Johansen wrote:
> So with the first use of conditional rules finally approaching we need to
> settle on the syntax.
> 
> In the past I have been using
> 
>   conditional=value
> 
> and for multivalue
> 
>   conditional=(value1 value2 value3)
> 
> eg.
>   owner=jj
>   owner=(jj fred)
> 
> with the () enclosed list format coming from the profile flags.  Basically
> just trying not to introduce yet another list format.  However this syntax
> has problems when variables are introduced on the left hand side.
> 
>   @{var}=value
> 
> looks like a variable assinment, and because variable assignment syntax
> is line oriented like includes, and it uses only spaces to separate its
> multivalue list
>   @{var}=value1 value2 value3
> 
> we can not distinguish a variable assignment and a conditional file rule
> if the proposed syntax is used.
> 
> There are a few possible solutions.
> 1. use == or some other symbol for equals
>   conditional==value
>   conditional==(value1 value2 value3)

This isn't the worst thing in the world imho, but is kinda ugly

> 2. Use a keyword to begin rules that can't be disambiguated
>    @{foo}=one /two three
>    file @{foo}=bar /etc/shadow w,

Seems this would make the policy harder to create/audit

> 3. use a different syntax for variables in conditionals (I think this would
>    be a mistake).

Me too

> 4. require the use of if keyword with conditionals (or at least variable
>    based conditionals
>    if @{foo}=bar
> 
>    In general I think this solution has problems as the conditional syntax
>    overlap rules specification for dbus, mount, network, etc.
>      dbus iface=foo method=bar,
> 
>    where if the value (iface, method) from above isn't specified it means
>    allow any iface, any method etc.
> 
> 5. never allow variable assignment within a profile.  This is currently
>    the case, but do we want to keep this restriction forever.
> 
> 6. never allow variable assignment within a profile once a rule has been
>    specified.  This would mean that variable conditional rules could not
>    be the first rule of the profile, but might be better than #5.

This seems an ok trade-off. Most profiles seem to use '#include
<tunables/global>' and if not that, the base abstraction. So long as the
parser has a clear enough error message and/or we are clear in the
documentation, #6 seems reasonable to me.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20120130/3e01bba3/attachment.pgp>