Hi John, I am trying to integrate in the Yocto build environment. As per my understanding there are two pieces, for kernel we have enabled apparmor related configuration in Kernel. On other hand user space related tools for apparmor, it looks we need python and perl as mentioned in apparmor_2.13.4.bb as PACKAGECONFIG.
Query: 1) As we are working on embedded boards,we have space limitations. So I would like to remove unwanted binary/utilities from apparmor build. 2) My goal is to capture the apparmor logs during compliant and enforce mode. Based on the captured logs, will generate a final profile and the final image will have a profile which will be started in enforcing mode. Can you please clarify, what are the mandatory packages for apparmor and any specific package (python,perl) version is needed. Do we have any details about which Yocto version (daisy or dunfell) supports the apparmor? Thanks Murali.S On Tue, Sep 8, 2020 at 5:00 PM John Johansen <john.johan...@canonical.com> wrote: > > On 9/8/20 1:22 PM, Murali Selvaraj wrote: > > > > 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? > > > strace, gdb > > AppArmor currently doesn't, especially with userspace code, but if you are > willing to patch a kernel and use apparmor 3 you make the gdb experience not > too bad. By causing the task to stop when an audit message is generated, you > can then easily use gdb to backtrace the stopped task. > > > > Does system() also could be pointed to comm="sh"? > > > yes, https://linux.die.net/man/3/system > > basically comm is set on exec and system() execs a shell. However I will > note tasks are free to change the value of their comm field, so you can not > rely on the value in that field > > > > > 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? > > > currently DAC_OVERRIDE will be available for every file the task tries to > access. But if that task is also confined by apparmor the set of files it can > access can still be limited. Capability DAC_OVERRIDE will not override an > apparmor file rule, not even the owner modifier. > > changing a file to 777 will make it available to a processes not just the > task that has DAC_OVERRIDE > > neither situation is great, the question becomes which is worse in your > scenario/deployment. If you are giving CAP_OVERRIDE to a network facing > daemon and not using any additional confinement, and that is the attack > surface you are worried about then changing a single file to 777 might be the > safer option. > > if you are running a university system with shared users who will push the > boundaries and the file is /etc/passwd or /etc/shadow the 777 is about the > worst thing you can do. > > TLDR: it really depends > > > > 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 ? > > you need to have apparmor profile attached to the process from its start. You > can reload and change the monitoring rules after the fact but currently there > is not way to change the processes confinement after the fact. > > > > > > > Thanks > > Murali.S > > > > On Tue, Aug 25, 2020 at 2:18 AM John Johansen > > <john.johan...@canonical.com <mailto:john.johan...@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. > > > -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
