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

[Mikhail Morfikov]

On 2018-04-02 09:33, John Johansen wrote:
> 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.
> 
Thanks for the answer!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180402/42c6d1e9/attachment.sig>