On 12/09/2017 12:12 AM, azu...@pobox.sk wrote: > > Citát John Johansen <john.johan...@canonical.com>: > >> On 12/07/2017 02:00 PM, azu...@pobox.sk wrote: >>> Hi, >>> >>> i have this rule in my profile: >>> owner /etc/passwd r, >>> >>> Problem is, that application is running under lots of different UIDs and >>> all of them are trying to access /etc/passwd (which is not needed, only >>> master process, running under root, needs it). How to get rid of the noise >>> in the logs? I cannot do 'deny /etc/passwd r' as it will deny also root >>> (master process) to access /etc/passwd. >>> >> >> you can try an undocumented unsupported experimental feature, that will be >> supported in the future but in a different form. Add the rule >> >> deny other /etc/passwd r, >> >> this will deny access to tasks with uids that are not the owner of the file >> (fsuid != file uid), and the deny will quiet logging because it is a known >> denial. > > > > Works fine, thank you! > > > > >> The other way is to use two profiles one for the master process and another >> for all the other processes that should not be accessing the file, but this >> can be inconvenient to set up. > > > Is this possible if application has no internal support for apparmor (so it, > for example, cannot change a hat to specified value when some event happens) ? > not always, and atm it can get tricky to do so sometimes. AppArmor's conditional attachment is limited to the file path atm (conditional attachment based on user is planned), which can be fairly limiting. However an application if launched from different profiles (say a user profile entered through pam_apparmor) then you can run the same application under different profiles. And of course you can manually force applications into a specific profile with aa-exec.
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
