Hi Seth, Thanks for the detailed explanation. Please go through below details and clarify further queries.
I do not see a capability difference when this script runs in root (UID:0) and nobody (UID>0). If we are observing the required capabilities when the script runs in root, that would be easy for us to find the needed capabilities for this script. Then we will apply this capability when it runs in nobody user. #!/bin/sh echo "Testing" while [ 1 ] do cat /etc/foo =================> Ensure this file belongs to root permission echo "TESTING" > /nvram/foo killall <root_process_name> sleep 5 done ls -ltr /etc/foo -rw-r--r-- 1 root root 8 Aug 3 20:31 /etc/foo Can you please check this script in your environment and share your observation. Please do the needful. Please execute in root and non-root mode and find the capability list from apparmor log events. *Need further clarifications:* My aim is to identify the required capabilities for the process when it runs in "non-root" user. Currently, this process runs in root mode, so by default all CAPs are enabled in Effective/Permitted CAPs. Analysis: -> While the process runs in non-root mode, we are planning to apply the capabilities before switching to non-root from root. So, we need to set appropriate capabilities in order to run the application successfully in "non-root". -> As per my assumption, we will find the required capabilities when the process runs in root-mode. To find the required CAPs list we thought to use "apparmor" logs while the process runs in compliant mode. Once we get the CAPs list from Apparmor logs, then we shall use the same required CAPS only ( NOT all the CAPs) for the process when it runs in non-root mode. -> The idea is that we are trying to drop root privilege using this method. Can you please confirm , the above method is possible in apparmor event logs to find the required CAPs at least when run in "root" mode. Thanks Murali.S On Mon, Aug 3, 2020 at 8:21 PM Seth Arnold <seth.arn...@canonical.com> wrote: > 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 >
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
