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 AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
