<div dir="ltr">Thanks for the explanation. Goal: Converting root process to non-root process by enabling required capabilities for the process. Scope: Am trying to find out required capabilities for the process which is going to run as "non-root" How to use Apparmor to find the capabilities specific to process: -> As per above discussion, Apparmor does not grant the required capabilities. -> We had thought that, from apparmor logs, we would be able to find the required capabilities. -> To find this, we would be following the steps to find the capabilities. Process (A) will be running in "non-root" but with all enabled capabilities and check the apparmor logs. Apparmor logs will show the required capabilities. Capture these CAPS and use this CAPS in the process code to convert that process root to non-root by only enabling this CAPs observed in apparmor logs. Is above understanding correct? please confirm the steps if anything is missing. General Query: In any event, AppArmor will usually see capability requests after the usual DAC permissions are handled. Can you please explain this above statement with simple example? For example, Process (x) tries to open a file (/etc/security) which is root permission but the process (x) runs in "non-root mode. Pls note, process (x) does not have permission to open this file ((/etc/security) ) open => sys_open() => kernel further code for handing the code. sys_open() => will return permission denied error due to permission issue. Here, capable() check won't happen. Does DAC take care of this check without using capability (CAP_DAC_READ_SEARCH)? In such a case, trying to understand when Kernel uses capable() to check CAP_DAC_READ_SEARCH/CAP_DAC_OVERRIDE before/after DAC. Can you please explain the relation between DAC, apparmor and linux capability with this context? Thanks Murali.S </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 4, 2020 at 6:08 AM John Johansen <<a href="mailto:john.johansen@canonical.com">john.johansen@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/3/20 8:02 PM, Murali Selvaraj wrote: > > 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 add echo -n "Confinement:" cat /proc/self/attr/current || echo "Failed to obtain confinement" ; exit 1 to your script after the killall or something similar, this will dump the confinement of the "cat" command but unless you have a transition for "cat" it should have the confinement of it parent or be denied. I should note that apparmor does have a dedup cache around logging capabilities. It is a single entry per processor (or virtual processor), and will prevent a previously seen cap from being logged IFF no other PROFILE has mediated a cap on that processor since the last time that profile previously logged the CAP in question. There is no manual switch to clear the cache, but it can be effectively cleared by replacing the profile but you need to actually make a change to the profile so that profile load dedup doesn't drop the replacement. > > 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. > not exactly your script but roughly equivalent unconfined non-root user killing root process $ kill 23579 bash: kill: (23579) - Operation not permitted no apparmor log message. ---- unconfined root user killing root process $ sudo kill 23579 success, no apparmor log message ---- confined non-root user without signal or CAP permissions killing root process $ aa-exec -p demo -- kill 23965 kill: (23965): Operation not permitted no apparmor log message ---- confined root user without signal or CAP permissions killing root process $ sudo aa-exec -p demo -- kill 23965 kill: (23965): Permission denied apparmor log messages [987021.379719] audit: type=1400 audit(1596533293.878:234): apparmor="DENIED" operation="signal" profile="demo" pid=24036 comm="kill" requested_mask="send" denied_mask="send" signal=term peer="/usr/bin/man" [987021.379727] audit: type=1400 audit(1596533293.878:235): apparmor="DENIED" operation="signal" profile="/usr/bin/man" pid=24036 comm="kill" requested_mask="receive" denied_mask="receive" signal=term peer="demo" notice no capabilities are needed to send the signal because its being sent from root to a root process ---- confined root user without signal or CAP permission kill a non-root process (different uids) $ sudo aa-exec -p demo -- kill 24690 kill: (24690): Operation not permitted apparmor log message [989073.431936] audit: type=1400 audit(1596535345.981:238): apparmor="DENIED" operation="capable" profile="demo" pid=24717 comm="kill" capability=5 capname="kill" finally we get a CAP request for kill The reason for this is that the kernel applies DAC mediation before LSM (apparmor) mediation. AppArmor never sees the permission request unless DAC allow the operation. > *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". > yes > -> 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. this doesn't quite work but you will be able to collect capabilities that don't rely on a uid check. This is because of how the kernel doesn't always apply a capability check, Eg. for kill CAPS are not always checked in the same way when subject uid == object uid vs. subject uid != object uid. The same can be said for DAC_OVERRIDE, DAC_READSEARCH, ... Some capabilities however aren't guarded by uid checks and you should be able to collect these caps when run as root. What you need to do to collect the full list of capabilities is give the non-root process all capabilities and run it. This should collect the full set of CAPs with how you are using uids. > 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. > close but see above, also you need to make sure exercise the application to get proper coverage > Thanks > Murali.S > > On Mon, Aug 3, 2020 at 8:21 PM Seth Arnold <<a href="mailto:seth.arnold@canonical.com" target="_blank">seth.arnold@canonical.com</a> <mailto:<a href="mailto:seth.arnold@canonical.com" target="_blank">seth.arnold@canonical.com</a>>> 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 > > </blockquote></div>