deny owner - what does it do?

[jonleivent]

I'm learning AppArmor, and have started studying your profiles. One thing I noticed in several is the use of "deny owner" file access rules. What do these do? Specifically, what does "owner" add beyond "deny"?

What is your policy about "deny" rules in general? My current understanding is that local profile includes can't override them, so probably you have some requirements for them. Do you use them only when there is a known or potential vulnerability that really should be prevented in all cases (something local profiles are unlikely to want to override)?

[roddhjav]

For example:

• deny @{HOME}/.secrets rw Denies all users to read/write the ~/.secrets file.
• deny owner @{HOME}/.secrets rw Only denies the user that own the file to read/write it.

The policy is to avoid to use deny as much as we can. Because by default everything is forbidden, the worst it can happen is to have our audit log file filled with apparmor DENY or ALLOWED rules. Vulnerabilities should normally be covered in profile without a special use of deny.

There are a few exceptions when we know we do not want to generate a lot of logs. Let's say we have a program called nautilus. It runs as our user and it needs to read/write all the files in our home directory. So we put something like this in the profile:

owner @{HOME}/{,**} rw,

However, now nautilus can also read file like @{HOME}/.secrets, and because it is in our home directory, nautilus will always try to read it. So we mostly use deny owner @{HOME}/{,**} rw, to keep clean log file. However, we don't use deny @{HOME}/{,**} rw, as we want to generate a log entry if nautilus wants to read someone else home directory.

[jonleivent]

@roddhjav
Thanks for that answer. That makes sense now. It also indicates something to beware of when authoring new profiles: how often a profile will cause a log message to appear that would only be an annoyance to the user.