[apparmor] Apparmor - Basic queries

[Murali Selvaraj]

Thanks for the explanation.

Can you please clarify the below queries.

1) After setting the process in compliant mode for the process, able to see
below logs.

2020 Sep 04 19:14:07 user kernel: audit: type=1400
audit(1599246847.756:1360): apparmor="ALLOWED" operation="capable"
 profile="Testing" pid=15084 comm="sh" capability=1  capname="dac_override"

comm shows "sh", it would be a shell script. I would like to find which
part of the code in the process needs dac_override capability.
I have cross checked the code, found a few instances but not able to
conclude which code really needs dac_override.
Do we have any method to find the corresponding code?

Does system() also could be pointed to comm="sh"?


2) Assume, my non-root process needs DAC_OVERRIDE to write a file which has
root permission.
  But this is only one instance in the code.

  In that case, if we enable DAC_OVERRIDE for this non-root process does it
show any security leak or just change the file permission as below
  chmod 777 <file>. Which option would be the best method for security?

3) To monitor the process behaviour using Apparmor, we need to restart the
process while monitoring the process for apparmor complain mode.
   In embedded products, some of the process will restart the system in
case of kill/restart the particular process.
   How can it be achievable for such a process using apparmor? or we could
not monitor those processes ?


Thanks
Murali.S

On Tue, Aug 25, 2020 at 2:18 AM John Johansen <john.johansen at canonical.com>
wrote:

> On 8/24/20 11:51 AM, Murali Selvaraj wrote:
> > Hi All,
> >
> > Please go through the below details and clarify with examples.
> >
> > Q1:How do we identify required capabilities from apparmor logs.
> >
> look for denials with the capname= field.
>
>
> > I am looking to find out the list of capabilities are used for the
> application/process using apparmor.
> > I have set up the apparmor and am able to see few capabilities NOT all
> CAPs in apparmor logs.
>
> AppArmor will only report on CAPs that make it to its module code. The
> kernel applies DAC and uid checks FIRST.
>
> eg. For capability DAC_OVERRIDE
>
>   the first check is if the task's uid == the object's (file's) uid if yes
> capability DAC override is not checked. If it they are different then the
> kernel will check the task's capability set, and if DAC_OVERRIDE is not in
> the set the operation will be denied and apparmor will never be consulted.
> Only if the operation requires DAC_OVERRIDE and the task's capability set
> has DAC_OVERRIDE will apparmor be checked.
>
> So the AppArmor profile's capability set is separate from the system set
> and Both have to allow the capability for it to be allowed.
>
> Also apparmor has a small 1 entry per cpu dedup cache so, that multipe
> requests to the same profile and capability will not be logged, if they are
> happening back to back (you just get one). Depending on your kernel there
> have been bugs in this caching so not all messages have always been
> correctly logged.
>
>
> > Do we have any simple exercise/method to find the required capabilities
> for the process specific from apparmor logs.
>
> No. We can come close by confining the application in a safe environment
> and exercising the application in complain mode. Or if you must deploy in a
> hostile environment in enforce mode, but you may have to restart the
> application due to denials changing code paths.
>
> > It will help us to set the required capabilities for the security reason.
> >
>
> AppArmor does not set capabilities but it can help you discover them
>
> > Q2:How do we know the process/application enough to cover  full code
> coverage for its required capabilities?
> >
> in short you don't, at least not without a lot of work. You can do code
> tracing and coverage based debug tools against the application to find what
> code has been exercised. And then you can do code analysis to ensure those
> covered parts get everything that could trigger capability requests. Even
> then you need to be careful to check the code to make sure its not using
> user defined data to set caps. If it does this you need to assume the user
> could request/set all ...
>
> > Do we have any suggested procedure/method to confirm the coverage of
> application, especially for real-time application?
> >
> Use tracing ftrace, .. or coverage tools like gcov
>
> > Q3:  In case of long run test cases, how to ensure all apparmor event
> logs are stored even uptime is more than 2 days?
> >
> Use auditd, you can control buffer sizes and whether messages can be
> dropped or whether system should panic if it can't log a message.
>
> > Do we have any configuration to keep apparmor logs for more than 2 days?
> >
>
> AppArmor does not directly control storage logs, instead it leverages the
> audit subsystem and your userspace auditing solution is in charge of that.
> So if you are using auditd (option with the most control of kernel
> messages) you would look at its options and configure it how you want/need.
> The other audit solutions rsyslog etc will messages from the kernel ring
> buffer and you again control how they are logged in the respective
> application config. I mention the difference as pulling from the ringbuffer
> doesn't provide all the same controls that auditd allows for from the audit
> subsystem.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20200906/f67a532e/attachment.html>