On 06/05/2016 11:22 PM, Guido Günther wrote:
> Hi Christian,
>
> Thanks a lot for your comments!
>
> On Mon, Jun 06, 2016 at 01:14:08AM +0200, Christian Boltz wrote:
> [..snip..]
>> You can enable the logging by adding the audit keyword, but the general
>> rule is not to log anything that is already handled (allowed or denied)
>> in the profile.
>>
>>> * a way to audit calls to subprocesses indicating whether the
>>> environment was scrubbed or not
>>
>> You'll get this information by reading the profile ;-) It already had
>> "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with
>> environment scrubbing.
>
> The rule tells me what the profile is supposed to do, not what it is
> doing. Ideally I'd like to debug this without modifying any rules.
>
> It's like the difference between reading code and debugging code. With a
> debugger I can see what the program is doing while the code tells me
> what it is supposed to do.
>
Another mode that might be helpful is forcing audit mode. This can be done
in two ways, to apply it globally
echo -n all > /sys/module/apparmor/parameters/audit
or by setting the mode on the profile
profile foo flags=(audit) { ... }
this will audit a message for every rule that apparmor allows. This can
be extremely noisy even just doing it for a single profile, so I would not
use the global option.
You will likely also have to turn off rate limiting by doing
echo 0 > /proc/sys/kernel/printk_ratelimit
even then the kernel ring buffer may overflow and you might lose messages.
Ideally I would like to add a full debug mode back in to apparmor, but
it was so noisy and lossy in the past that it was almost useless. It
got ripped out in the cleanup/rewrite and will resurface when we can
better control it. We do have some ideas, like being able to specify
a set of rules to trigger events (audit, or signal on). A signal to stop
tasks so a debugger can have a chance to introspect and catch up on
the debug stream etc. Not that that helps you as it is not available
yet.
