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

[John Johansen]

On 12/19/2010 07:04 AM, Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 17. Dezember 2010 schrieb John Johansen:
>> On 12/03/2010 07:37 AM, Christian Boltz wrote:
>>> Does somebody have a list of changes to the profile format between
>>> AppArmor 2.3 and 2.5?
> 
>> Hey Christian sorry this got dropped.  The answer is very little has
>> actually changed at the profile language level.  Most of the time has
>> been spend rewriting parts, and doing under the hood improvements,
>> instead of getting new features in.
> 
> Well, the changes aren't too big, but some of them (for example 
> "permissions before match") will double the vim syntax file size.
> I'm thinking about generating it using a script... (perl or php - perl 
> might fit better, but I'm more familiar with php ;-)
> 
>> So the changes that I can think of that currently extend 2.3 are
>>
>> New x transitions
>>   pix, Pix - which tries px and then falls back to ix if the profile
>> doesn't exist
>>   pux, Pux - same thing as pix except falling back to ux
> 
> already existed in 2.3 ;-) and works with existing apparmor.vim
> 
>> New capabilities have been added
>>   audit_write, audit_control, 
> 
> Those sound like they should be highlighted as "dangerous" (like 
> sys_admin)
> 
yep

>>   set_fcap, 
> 
> I read in capabilities(7):
>     Permitted (formerly known as forced):
>         These capabilities are automatically permitted to the thread, 
>         regardless of the thread's inheritable capabilities.
> 
> Sounds like it should also get the "dangerous" flagging.
> 
>>   mac_override, mac_admin
> 
> capabilities(7) is not really informative about those - what do they do? 
> Should I flag them as "dangerous"?

AppArmor and smack use then to determine if a process can manage policy etc,
so very dangerous

> 
>> Profile names can now have globing in them,
>>   eg.
>>   /** {
>>   }
>>
>>   would define a default profile.  Matches are prioritized by longest
>> left /bin/** { }  would be the preferred match over /** { }, etc. 
>> with the exact name being the most preferred match.
> 
> That already works with the current apparmor.vim ;-)
> 
>> The profile flags= keyword is now optional
>>   eg.  /foo flags=(complain) { }   can now be written as /foo
>> (complain) { }
> 
> OK, simple one.
> 
>> There some new profile flags
>>   attach_disconnect, no_attach_disconnected,  chroot_attach,
>> chroot_no_attach, chroot_relative, namespace_relative
> 
> OK
> 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)

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

>> include statement do not require # infront of them any more
>>   #include <abstractions/base>
>>   include <abstractions/base>
> 
> Also an easy one.
> 
>> 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.

> What about the keywords like owner, user and audit? can they also be 
> placed anywhere or do they have to be at the beginning of the line?
> 
they have to be at the begging of the line

> Examples - which of them are allowed?
> owner rw /foo,
good

> rw owner /foo,
no

> rw /foo owner,
no

> owner /foo rw,
good

> /foo owner rw,
no

> /foo rw owner,
no

> 
> Talking about keywords - how does the exact syntax of user=... look 
> like?
> 
the proposed syntax for owner= and user= is

owner=<name> <whitespace> <rule>
owner='('<names>')' <whitespace> <rule>

where the list followed the syntax for the flags value, however the list
syntax part needs to be made consistent, ie. we either need to fix the
flags list separator or make the list separator here the same as flags
and also fix it for variables, etc.  switching flags to use just whitespace
is by far the easiest.

So going with the whitespace separator we would have
owner=jj /foo r,
owner=(jj) /foo r,
owner=(jj smb) /foo r,


>>   for named transitions it is written like
>>   /foo px -> bar,
>>   px /foo -> bar,
> 
> Works already :-)
> 
>> In the current development versions it will possible to name a
>> profile, eg.
>>   profile firefox /usr/bin/firefox-* { }
>>
>>   this makes the profile spec look something like
>>
>>   [profile] <attachment> [[flags=](<flags>+] { }
>>   profile <name> [<attachment>] [[flags=](<flags>+] { }
>>
>>   where names must start with an alphanum
>>   and attachment must start with / or @{varname}
> 
> OK, so the new thing is the (optional) name.
> 
yep

> I remember that 2.3 allowed
> profile unattached.profile { ... }
> so enforcing / or @ as start doesn't sound too good ;-)
> 
> However, I should probably include the variable pattern to enforce 
> "@{...}" ;-)
> 
right

> Remaining things from 
> https://apparmor.wiki.kernel.org/index.php/TechnicalDoc#Capabilities 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.
The idea behind those was a way to enhance the capabilities and remain
backwards compatible.

And use the syntax for each would have to be capability (or type specific)

eg. for chown we could have a path and user

  chown /foo to (user1 user2),

but for setuid it wouldn't have a path.
   setuid to (user1 user2)
 

> uses ipc,
> ipc rw /profile,
> ipc signal w (child) /profile,
> deny ipc signal w (kill) /profile,
> 
> 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.


> That all said: are there some example profiles I could use to test 
> apparmor.vim?
> 
Hrmmm, yes.  The goal is to keep adding to the parser test suite, and
get it to contain at least on example of every valid syntax and also
example profiles of invalid syntax.  I won't say that the coverage
is complete yet but it does have hundreds of simple examples.

it can be found in parser/tst/simple_tests/