> > > 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 <[email protected]> > 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. >> >>
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
