[apparmor] Is there a way to disable logging for a specific profile?

[John Johansen]

On 03/30/2018 09:23 AM, Mikhail Morfikov wrote:
> AppArmor has a feature that allows it to log messages, and that behavior can be
> controlled via /sys/module/apparmor/parameters/audit . But according to some
> docs I've found, this logging mechanism is rather limited -- basically logging
> can be enabled or disabled for all profiles at the same time.
> 
Unfortunately this is indeed the case atm.

> In some cases, it's really hard to profile an app because it shouldn't access
> all files in some example directory. I mean, you can add some exception (path)
> in the AppArmor profile for that file, and the rest of the files in the
> directory will be denied by default. The problem is that you'll get spam of the
> denied messages in the syslog, and how to deal with this? You can't use
> something like the following:
> 
>      /dir/file1 rw,
> deny /dir/** rw,
> 
> In this case all the files under /dir/ will be denied and no logs will be
> printed. The only way to deal with this situation is to deny every single file
> under /dir/ (except file1), but sometimes the content of /dir/ can change, and
> the task of getting rid of the messages from the syslog is impossible. You could
> probably filter the file somehow, for instance, by extensions, but what when
> files don't have any extensions?
> 

yes this is problematic and there is wip to improve this. Specifically
there will be some new flags for profile level control, rule
qualifiers allowing for better control at individual rules, and there
will be some support for boolean operations in policy.

Eg. you would be able to write

  deny /dir/** - /dir/file rw,

so that you can deny every thing in a directory except certain files.

> I thought I could disable logging for a specific profile using some flags, for
> instance:
> 
> ...
> /usr/bin/app flags=(nolog)
> ...
> 
> So after I create a profile, I would add this flag and don't care whether
> something is silently denied for the app, of course till the app works as
> expected, and at the same time I would be able to see logs from other profiles.
> But this simply doesn't work.
> 

sadly not yet. There will be some new flags coming, but those will
require both kernel and userspace updates.

> Other solution I could also think of is to add a rule like the following:
> 
>       /dir/file1 rw,
> nolog /dir/**,
> 
> In this case, logging would be enabled for the profile itself, but any access to
> files in /dir/ would be silently denied. Of course, the app would have access to
> the files in the directory that are specified in the AppArmor profile.
> 
> Are the logging features possible to implement?
> 

yes, and more. However some changes will require not just changes in
userspace but also in the kernel. So some features will only be
available on newer userspace + newer kernel, while others will be
available with just an update to the userspace.

The boolean operations mentioned above and rule specific quieting of
audit (noaudit), is possible with just a userspace update.

A profile wide noaudit flag is possible from userspace if the compiler
turns it into per rule noaudit flags. The only disadvantage here is
you would not be able to turn it off per profile (but current kernels
don't support doing that so there is no loss for current kernels).


> I also wanted to ask about mime types. Files have filenames, but the content of
> a file is independent of the filename or a file path. In this way, when you
> don't want the app to access some file based on the path name, AppArmor can
> block access to the file. If you change the name of the file, the file doesn't
> really have to be denied anymore (could match some rules in the profile), and
> the access will be granted. But what about mime types? Basically if a file has a
> "video/x-msvideo" type, AppArmor would deny access to this specific type, and
> the app wouldn't be able to open the file no matter where the file is located.
> 
> Is this feature possible to implement in AppArmor, or this can't be done?
> 

It is possible but there are some caveats. First it will greatly
depend on where/how the types are stored. If they are tagged on the
file in a well known xattr it will be possible in the future to use an
xattr conditional match.

If however the mime type is derived by an external database or by
scanning the file, a userspace helper will be required. AppArmor
currently does not support an upcall to a userspace helper but it is a
commonly requested feature and it will likely be added at some
point. It then would be a matter of extending such a helper to provide
the mime type mediation.