[apparmor] apparmor.vim - profile format changes since 2.3?

[John Johansen]

On 01/09/2011 08:58 AM, Christian Boltz wrote:
> Hello,
> 
> Am Thursday 06 January 2011 schrieb John Johansen:
>> On 12/19/2010 07:04 AM, Christian Boltz wrote:
>>> Am Freitag, 17. Dezember 2010 schrieb John Johansen:
>>>> On 12/03/2010 07:37 AM, Christian Boltz wrote:
> ...
>>> BTW: What is used as word separator if more than one flag is given?
>>> flags=(foo,bar) (whitepace allowed?) or flags=(foo bar)?
>>
>> its the comma and leading whitespace gets eaten
>> so
>>   flags=(foo,bar)
>>   flags=(foo, bar)
> 
> Is whitespace also valid at other places? Some examples:
> 
yes, whitespace is ignored, currently the "," is required in the flags
syntax but not anywhere else.  Of course the problem with using the
comma as a list separator else where is that it is used as a rule
terminator

>     flags=( foo )
>     flags= (foo)
>     flags = ( foo , bar )
these all work

> 
> (At the moment I allow "flags=( foo )")
> 
>> I'm not really happy with how this is inconsistent with the space
>> separator used else where.
>>   eg.  @{foo}=abc def
>>
>> and since we have never to my knowledge used multiple flags in a
>> profile it might be worth changing
> 
> Well, in theory even in 2.3 one could have used flags=(complain,audit) 
> so I'd say: allow both space and comma, but document only space ;-)
> 
yeah I think this is the solution, I will go with an paran enclosed list
the comma will be allowed as the separator, and whitespace will just get
eaten.  So
  flags=( foo bar)
  flags=( foo, bar )
etc will just work

> BTW: I have a "debug" flag in sdFlagKey, but not in sdFlags. Is "debug" 
> a valid flag?
> 
hrmmm, it used to be but it isn't currently valid, though I can think of
a few places it would be nice to have extra debug output, so  I can see it
coming back in some form.

> BTW2: I dediced to use the very visible flag highlighting ("TODO" color) 
> only for complain and debug. I'm no longer using it for audit, and I 
> also don't use it for all the new flags. (Objections?)
> 
no, sounds reasonable to me

>>>> permissions can be specified before the file match.
>>>>
>>>>   rw /foo,
>>>
>>> That will double apparmor.vim size (see beginning of the message).
>>
>> yeah, not sure adding that was wise but there were a few people who
>> really wanted that feature.
> 
> For now, I won't implement that - having an otherwise up-to-date 
> apparmor.vim in openSUSE 11.4 is more important ;-)
> 
Makes sense, the tools don't support it yet either.  In fact that is the
general state for almost anything that is new.  The kernel and parser
lead the tools by at least a release.

> Talking about file rules - I somewhat remember to have read that there 
> is a fixed order for the owner, audit and deny keywords of file (and 
> other?) rules. Am I right about this? If yes, which order?
> 
Yes there is

[audit] [deny] [owner]

>>> Talking about keywords - how does the exact syntax of user=... look
>>> like?
>>
>> the proposed syntax for owner= and user= is
> 
> Does "proposed" mean that it is not yet implemented?
> (Then it would be pointless to allow it in apparmor.vim.)
> 
It isn't supported in any release yet.  If I can finish up the extended
conditional support in the next couple of weeks it will be part of the
2.6/3.0 release coming up this spring.

Whether its 2.6 or 3.0 will depend on whether we get far enough to
require the version tag because we break semantic compatibility with
certain older rules (eg. whether there is a required mount rule etc).

I think the syntax is now pretty firm as no one has complained about it
and its been kicked around for more than 2 years.

>>> Remaining things from
>>> https://apparmor.wiki.kernel.org/index.php/TechnicalDoc#Capabilitie
>>> s are IMHO:
>>>
>>> owner=(foo,bar) something,   # "owner something" already works
>>>
>>> capability dac_override {
>>>     /file/bar rw,
>>> }
>>> capability chown {
>>>    /file/bar (user1, user2),
>>> }
>>> (Are those things specific to dac_override and chown?)
>>
>> Hehe, now your veering even more into unimplemented stuff :) Those
>> where merely proposed syntax and I don't believe we are using them
>> now. 
> 
> OK, then I won't implement it until it is supported ;-)
> 
:)

>>> uses ipc,
>>> ipc rw /profile,
>>> ipc signal w (child) /profile,
>>> deny ipc signal w (kill) /profile,
> 
> Are those implemented or only proposed?
> 
proposed, though the base ipc may hit this spring, it will all depend
on the next few weeks.

>>> Which keywords can apply to ipc? I'd guess audit and deny. What
>>> about owner?
>>
>> owner and user could be selectively applied but not to allow of ipc
>>
>> owner doesn't really make sense for signal, but user might this is
>> just another place we need to look at before we commit to the
>> syntax.
> 
> [example profiles]
>> it can be found in parser/tst/simple_tests/
> 
> Good to know.
> 
> That all said: attached is an updated apparmor.vim that should support 
> the latest syntax, except if stated otherwise above.
> Please test it and give some feedback ;-)
> 
thanks, I haven't had a chance to test yet but I know it will be getting
a work out in the next few weeks.

> I'm also attaching my "build system" for apparmor.vim (apparmor.vim.in 
> and the make script) for several reasons:
> - to let you see what I'm doing internally
> - to make it easier to send me a patch (even if I hope it won't be 
>   neccesary)
> - to have a remote backup ;-)
> 
thanks Christian