[apparmor] understanding apparmor_parser debug output

John Johansen john.johansen at canonical.com
Fri Mar 31 23:55:12 UTC 2017

On 03/31/2017 02:48 PM, Vincas Dargis wrote:
> Hi,
> I'm on Kubuntu 16.04 with Apparmor 2.10.95-0ubuntu2.6 and Linux 4.8.0-34-generic (HWE)
> usr.bin.skype profile has such lines:
>   deny @{HOME}/.fontconfig/ w,
>   deny @{HOME}/.fontconfig/*.cache-*.TMP* w,
> When I run:
> apparmor_parser -Q -d  /etc/apparmor.d/usr.bin.skype
> These lines are printed:
> Mode:    wa:wa    Name:    ({/home//*,/root}/.fontconfig/)
> Mode:    wa:wa    Name:    ({/home//*,/root}/.fontconfig/*.cache-*.TMP*)
> I do not quite follow here. What these wa:wa means exactly? Looking at Wiki [0], it kinda seems like if I am owner or not, I am allowed to write..? Though of course I expect not to be able to write due to "deny".
its showing the internal permissions that the w is mapping to. That is w is being converted to both write and appaend internally. This due to how permissions get tested. The colon is used to represent user:!user, which is again just an internal mapping detail and could change in the future. The denied info is stored as a separate flag, and I would say it is a bug that debug is not outputing it.

> How to interpret these debug outputs, how do I audit apparmor profiles?

Auditing apparmor profiles is unfortunately a lot harder than it should be atm.

I tend to use apparmor_parser -p, to get a flattened view of the profile with all the vars etc in one place, but this currently can lead to a lot of duplication. Depending on what I am looking at I use some of the dump flags as well
--help=D will provide a list of what the parser supports. This list can change, it is not considered as stable api, hence it not being documented in the man pages.

the one that would probably interest you is
[no-]rule-exprs              	Dump rule to expr tree conversions

which will dump out information about rule conversions
it will dump a whole bunch of stuff like

aare: /proc/stat   ->   /proc/stat
rule: /proc/stat  ->  /proc/stat (0x10004/0)< 0x10004>

however this requires you to know even more of the internals and may not be useful, depending on what you are doing

Overall, I would say auditing profiles is far to hard at the moment and we need some lint, and auditing tools to help with the process

> Thanks.
> [0] http://wiki.apparmor.net/index.php/AppArmorMonitoring - "This listing shows the permissions granted when the user owns the resource (file, directory, pipe, etc.) and when the user does not own the resource."

More information about the AppArmor mailing list