[apparmor] AppArmor and kernel capabilities

[Seth Arnold]

Hello,

On Tue, Sep 12, 2017 at 07:04:06PM +0200, linux maillist wrote:
> I creates a profile for gpg and that profile requested now the
> capability dac_override.
> 
> This raises some questions to me. First, does dac_override honor the
> folder permission rules within the profile? For example, if there is a
> rule "/foo/** r," does dac_override this rule?
> 
> If dac_override still honors the folder rules, what then is the point to
> ask for that capability?
> 
> Lastly, why is that capability requested at all?

Here's the text from capabilities(7):

       CAP_DAC_OVERRIDE
              Bypass file read, write, and execute permission
              checks.  (DAC is an abbreviation of "discretionary
              access control".)

       CAP_DAC_READ_SEARCH
              * Bypass file read permission checks and directory
                read and execute permission checks;
              * Invoke open_by_handle_at(2).

So gpg was run as root and tried to read, write, or execute, a file
(or write to a directory) that it did not have access to via the usual
Unix permissions. It was able to operate on the file because it was run
as root and had CAP_DAC_OVERRIDE in its effective permissions.

Now the sad news -- there's no easy way to see what operation was
requested. At the point when the kernel asks AppArmor if this capability
should be allowed we don't have any context on what the operation is, so
we can't report anything better. auditd has an option to log syscalls --
which can be enabled for usual dmesg logs via
/sys/modules/apparmor/parameters/logsyscall -- but it will tell you the
values of the pointers given to the system call rather than the paths that
were used.

So your best bet to figure out why this value is needed is to load
a version of the profile without the capability and either (a) hope
gpg reports a good error message when it gets permission denied or (b)
use strace to find out what it was doing when it gets the error. strace
modifies so much of the execution environment that it would be my last
resort method.

> Normally AppArmor complains if r/w to a certain file/folder is needed.
> But, here a capability was requested.
> Requesting dac_override does not give any hint, what file or folder is
> required to access...

In the long run I think it should be possible to use the kernel's
perf facility to log _some_ kind of details on-demand when profiling
an application. It probably wouldn't be something you'd want to have
running all the time but it feels like this should be possible.

I hope this helps.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170912/0f8e30f1/attachment.sig>