>
> Hi John, Seth,
>
> Thanks again for the details. I would like to get your inputs and clarify
> my understanding.
> Please go through the trailing email and correct me if I am wrong.
>
> *Goal:* Reducing root permission of the process and enabling required
> capabilities for the process.
>
> *Design and approach:*
>
> - To identify the required CAPs for the process, we are planning to enable
> all CAPs while running in "non-root"
> mode and from apparmor logs, hopefully we would be able to find the
> required capability list for the process
> specific.
>
> - Please note that our user "non-root" (UID) is fixed. we won't change the
> user UID and GID for non-root.
>
> *Implementation:*
>
> - Process would be starting as "root" and dropping to non-root then
> applying required CAPs based on above apparmor logs
> using libcap APIs.
>
> - Most of the process needs CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH to
> read/write root privilege files/directories.
>
> *Query specific to above non-root approach: *
>
> - We are planning to enable CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH CAPs
> when the process switches to non-root.
> - Then based on a process for example network specific process, we will
> enable CAP_NET_ADMIN.
> - In case of system specific processes to access hardware details, we will
> enable CAP_SYS_ADMIN.
> - Please note, we will require CAPs based on apparmor logs as indicated
> above.
>
> Here, the doubt is that if we enable CAP_DAC_OVERRIDE,
> CAP_DAC_READ_SEARCH, CAP_NET_ADMIN, CAP_SYS_ADMIN to run
> the process in non-root to ensure it works in the same way when it was
> running in "root".
>
> Do you think enabling CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
> CAP_NET_ADMIN, CAP_SYS_ADMIN in the process
> are we missing any security or this is expected while using Linux
> capabilities for non-root (dropping root privilege).
>
> Please share your valuable suggestions on security specific views.
>
> *General query:*
>
> - Is Linux capabilities belong to DAC or LSM/MAC?
> As per my understanding, Linux capabilities are part of LSM. But I still
> think that few CAPs are used in DAC.
> Please share the details with example.
>
> - Is LSM mandatory to enable in Linux Kernel?
>
> - Which LSM is enabled in linux by default?
>
> - Why do we need MAC as we have a security check by discretionary access
> controls (DAC) ?
> Is MAC mandatory to enable or optional?
>
> - Is MAC really mandatory for Linux? AS per my understanding, for embedded
> linux devices no need to enable MAC on production devices.
>
> Thanks
> Murali.S
>
> On Wed, Aug 5, 2020 at 3:25 AM John Johansen <john.johan...@canonical.com>
> wrote:
>
>> On 8/4/20 7:46 PM, Murali Selvaraj wrote:
>> > 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.
>> >
>>
>> Yes AppArmor with the caveat that the "non-root" user is the one you plan
>> to use in the future. Any "non-root" user will likely work but I can't
>> guarantee it unless you use the same uid.
>>
>>
>>
>>
>>
>> > *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?
>> >
>>
>> The kernel applies multiple checks (eg. input validation) and the kernel
>> bails on the first failed check. A pseudo code of this idea is
>>
>> fn () {
>>
>> if (input bad)
>> return fail;
>>
>> if ( task uid != object uid) {
>> if ( not capable (CAP))
>> return fail; }
>> if ( not APPARMOR_CAP(CAP)) <---- AppArmor will log if
>> we get here
>> return fail;
>> }
>>
>>
>> The kernel generally does multiple checks like explained in the pseudo
>> code above. The general pattern is the same as in the pseudo code too. That
>> is input validation comes first, then object lookup, then DAC based
>> permission check (regular unix capability and uid checks), and then the LSM
>> (apparmor) based checks. But code gets grouped into reusable fns and some
>> time fn order can result in a MAC (apparmor) happening before the DAC check.
>>
>> The overlarching pattern is DAC comes first but there are a few cases
>> where AppArmor is checked first, however you can be assured all required
>> checks will happen.
>>
>>
>> > 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)?
>> >
>>
>> yes DAC includes uid and guid checks. The capability call for
>> CAP_DAC_READ_SEARCH only happens if the uid/guid checks fail.
>>
>> > In such a case, trying to understand when Kernel uses capable() to
>> check CAP_DAC_READ_SEARCH/CAP_DAC_OVERRIDE before/after DAC.
>>
>> these capabilities are only checked if the uid/guid check fail, in which
>> case the task will need these capabilities to access the file
>>
>> ie. if you own the file you don't need CAP_DAC_OVERRIDE
>> if you are in a group that allows access to the file you don't need
>> CAP_DAC_OVERRIDE
>>
>> > Can you please explain the relation between DAC, apparmor and linux
>> capability with this context?
>> >
>>
>> Its generally follows the pattern outlined in the pseudo code above, but
>> the pattern does vary with the hook and object. The reality is more
>> complicated than the pseudo code.
>>
>> There are hooks where you get multiple DAC checks (uid and cap) an
>> multiple LSM checks. Eg. some file operations will be closer to the pattern
>>
>> input validation
>>
>> object lookup
>> loop on path elements
>> DAC uid check
>> DAC capability check
>> MAC capability check
>> MAC inode check
>>
>> MAC path check
>>
>> MAC inode check
>>
>>
>> so there are potentially checks on every element of the path walk, and
>> also checks at the operation type (eg. mmap, chown, ...)
>>
>>
>>
>> > Thanks
>> > Murali.S
>> >
>> > On Tue, Aug 4, 2020 at 6:08 AM John Johansen <
>> john.johan...@canonical.com <mailto:john.johan...@canonical.com>> wrote:
>> >
>> > 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 <
>> seth.arn...@canonical.com <mailto:seth.arn...@canonical.com> <mailto:
>> seth.arn...@canonical.com <mailto: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
