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
signature.asc
Description: PGP signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
