[apparmor] Apparmor: Query

[Seth Arnold]

Hello Murali,

On Mon, Aug 03, 2020 at 02:03:38PM -0400, Murali Selvaraj wrote:
> Query 1:
> 
> - But I do not see CAP_DAC_OVERRIDE and CAP_KILL in apparmor event logs.

AppArmor does not have a mechanism to grant capabilities that a process
does not already have. The kernel will query LSMs to see if a capability
is allowed to be used if the process already has the capability in
question. (There may be exceptions to this, there's hundreds of these
checks scattered throughout the kernel.)

You'll only see these requests in AppArmor logs if the process had these
capabilities. By using su to switch to the 'nobody' account, you only have
access to whatever privileges the nobody account already has: additional
access to root_squashed files on NFS, any other processes mistakenly
running as user nobody, etc.

Because this doesn't include any capabilities in the process's
capabilities sets, AppArmor won't even see the requests.

> Query 2:
> 
> - How apparmor identities how many capabilities are needed for the process?

The kernel will call capable() in the codepaths as necessary; the security
module interface will get the calls, without context, after the rest of
the kernel's capabilities handling. It's difficult to follow because it's
been heavily optimized for performance.

In any event, AppArmor will usually see capability requests after the
usual DAC permissions are handled.


> Query 3:
> 
> - Does all system calls need capability when it runs in a non-root process,
> how does apparmor mapping the linux capabilities?

"root processes" means both uid 0 as well as having capabilities in the
effective capability set. (Perhaps it'd also make sense to consider the
other capability sets in the process?) A uid 0 process with no
capabilities still has considerable power, since many important files like
/etc/sudoers are owned by uid 0, and modifying these files through DAC
permissions alone could be used to then gain capabilities. However, a uid
0 process with no capabilities couldn't itself initiate a reboot in the
kernel, or override DAC restrictions on files, etc.

A process with capabilities need not be uid 0 though I can't immediately
point any common examples.

Linux's uid namespaces makes things a bit more complicated: a process can
have namespace-level capabilities that do not extend to capabilities in
the init namespace. (Consider something like an LXD guest: there may be
different users within the guest, and the 'root' user with the LXD guest
can do privileged operations over the namespace, eg manage the routing
table used for that network namespace, but not be able to manage the
routing table used by the network namespace for the init process.)

See the user_namespaces(7) and unshare(2) manpages for some more information.

> Can someone please clarify these queries?

I'm afraid my description probably made things worse.

Let me try one quick simple thing:

Run your example with and without root privileges. You'll see the
difference in AppArmor log output. Hopefully that helps. :)

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