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

Christian Boltz apparmor at cboltz.de
Sun Dec 19 15:04:22 GMT 2010


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 

>   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"?

> 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

BTW: What is used as word separator if more than one flag is given?
flags=(foo,bar) (whitepace allowed?) or flags=(foo bar)?

> 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).

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?

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

Talking about keywords - how does the exact syntax of user=... look 

>   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.

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 
"@{...}" ;-)

Remaining things from 
https://apparmor.wiki.kernel.org/index.php/TechnicalDoc#Capabilities are 

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?)

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 

That all said: are there some example profiles I could use to test 


Christian Boltz
Confixx hat der Teufel erfunden, und weils so schmerzhaft ist,
gleich danach Plesk. [Jim Knuth in postfixbuch-users]

More information about the AppArmor mailing list