[apparmor] Exporting to AppArmor syntax

[Cliffe]

On 21/01/2011 4:10 PM, John Johansen wrote:
> On 01/20/2011 11:32 PM, Cliffe wrote:
>> Hi guys,
>>
> Hi Cliffe,
>
>> As I have mentioned in the past, I am (slowly) adding "export to AppArmor profile" features to FBAC-LSM policy manager. (http://schreuders.org/FBAC-LSM) The main features more or less work at the moment, The FBAC-LSM gui can export to and manage FBAC-LSM created AppArmor profiles. However, I have a few questions about syntax and the audit logs.
>>
>> I am using OpenSUSE 11.3, and I am using the standard OpenSUSE kernel (and whatever version of AppArmor comes standard, therefore likely an older version). At the moment, I am not using any of the AppArmor libs since I don't want the dependencies.
>>
> understood, they won't help you too much at the moment anyways.
>
>> FBAC policy stores a list of executable paths that specify which processes are restricted by an application policy.
>> For example:
>>
>>      /usr/bin/opera
>>      /usr/bin/X11/opera
>>      /usr/lib/opera/**
>>
>>
>> What would the AppArmor profile name look like?
>> This seems to work:
>>
>>      /{usr/bin/opera,usr/bin/X11/opera,usr/lib/opera/**}
>>
> yeah this should work,
>    or /usr/{bin/{X11/,}opera,lib/opera/**} if you wanted more factoring but that is harder to read
>
> the most recent development version also allows associating a name separate of what is specified
> for the attachment, which is useful for dealing with this type of profile eg.
>    profile opera /{usr/bin/opera,usr/bin/X11/opera,usr/lib/opera/**} {
>      ..
>    }
>
> but since this isn't widely available I wouldn't worry about adding support for it yet.
>
>> Is this globbing correct, or should it be regex? What are the special characters for this match?
>>
> Well AppArmor currently doesn't expose support to the full regex engine atm, so it has to be globbing
> atm.

Ok, thanks. FBAC-LSM uses simplified AppArmor-like wildcards so that is 
not a problem.

> I'm not sure what you mean by special characters for the match, the characters that ** won't match
> perhaps?  The only character that ** won't match is \000 the null character which isn't a valid
> filename character in linux.

I just meant characters treated differently for globbing etc. I suppose 
these are all the standard AppArmor file globbing characters such as 
[,],*,**, {, }, ?. (As described in the online documentation). I need to 
escape those that FBAC-LSM doesn't treat as special when converting from 
FBAC rules.

>> I am thinking of making the FBAC-LSM learning mode also work with AppArmor.
>> With my current version of AppArmor I get messages in this format in /var/log/audit/audit.log
>>> type=APPARMOR_DENIED msg=audit(1295431719.156:15924): operation="open" pid=18946 parent=2607 profile="/{usr/bin/vlc,usr/bin/X11/vlc,usr/lib/vlc/**}" requested_mask="r::" denied_mask="r::" fsuid=1000 ouid=1000 name="/home/cliffe/.config/Trolltech.conf"
>>> type=APPARMOR_DENIED msg=audit(1295431719.168:15927): operation="open" pid=18946 parent=2607 profile="/{usr/bin/vlc,usr/bin/X11/vlc,usr/lib/vlc/**}" requested_mask="::r" denied_mask="::r" fsuid=1000 ouid=0 name="/etc/udev/udev.conf"
>> What is the difference between mask="r::" and mask="::r"?Is there any documentation that describes this?
> I know I wrote documentation on this but I can't find it atm, in general everything should be at apparmor.net
> which redirects to the kernel.org wiki
>
> r:: is user and ::r is the permission for not user.  Its an older format that came about when we were going to
> do a user:group:other style triplet.  However that had limitations that we really didn't want and we are
> moving back to just plain permisions without the ::, and having uid and oid info in every log message so
> the ownership can be figured out that way.

Ok. I'll just ignore ":" then.

>> Also, out of curiosity, how are the policy intersection features coming along? By default FBAC intersects most policies (for example, so that helper programs can't exceed the privileges of the programs they are working for), so an intersection permission rule would help with the export.
> Sadly I haven't worked on them at all.  The cleanups and extension to file mediation, conditionals, ipc,
> and networking are all coming first.  Once we get this base solid we can get back to stacking of
> profiles.

Ok. No worries :)

Thanks for all the info.