More audit log output for debug stacking profiles.

[Mikhail Kurinnoi]

I am faced with issue, that the stacking is hard to debug, since audit log don't provide any information that could help.

Is it possible add more audit log information output for stacking profiles, such as parent's profile name and full stacking line in profile="" instead of first profile used for stacking?

I am sure, we will also need this for Delegation feature, that planed in future.

[John Johansen (jjohansen)]

Its possible, but would only be for a debug mode with correct authority. Can you provide more info as to what the situation was that was hard to debug with just the profile name.

There are a few reasons that just the profile is reported.

- The whole stack may not be visible, and it would be considered an information leak to make that information available.
- If the denial is coming from one of apparmor's trusted helpers (dbus, ..) it may not even have access to the full context.
- Even when the stack is visible reporting the other parts of the stack not responsible for the denial can be confusing to those trying to develop policy, as separating out at the per profile level identifies the specific entities that have to be modified.

As for delegation yes some additional information is needed and will come in the form of
profile="firefox//+12345" where the +12345 is unique to the set of delegation rules. Unfortunately this will either require digging into the system to find what that means. Or additional logging, but is required because logging all the delegation info is even worse than logging all the stacking info.

[Mikhail Kurinnoi (viewizard)]

> Can you provide more info as to what the situation was that was hard to debug with just the profile name.

For example:

profile p1_root {
/bin/test Px,
}

profile p1_root_sudo {
/bin/test Px -> test//&root_sudo,
}

I was interested in solution for RBAC, when I have:
1) "real" root
2) user in wheel group, switched to root by sudo, that should have more limited then "real" root rules.

For now, I have different tree for "sudo" root that starts in "sudo" hats. I think, stacking with "mask" profile "root_sudo" will be the best solution in order to use "real" root profiles I already have in system, so, I will could finally remove "sudo" root profiles for programs. But I found, that I can't identify which one was used, since I see in audit log same profile="", name="", ouid="", etc.

> There are a few reasons that just the profile is reported.

Thanks for explanation.

> As for delegation yes some additional information is needed and will come in the form of
> profile="firefox//+12345" where the +12345 is unique to the set of delegation rules.

I am just worry, is it planed as "static" unique ID, that will be generated during binary cache creation (for example), or "dynamic", that will be generated on each profile load? I mean, will I be able analyze audit log files after reboot/shutdown?