[apparmor] Apparmor - Basic queries

Tue Sep 8 20:22:40 UTC 2020

>
>
> 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/20200908/fa28dc6c/attachment.html>