On 10/12/20 2:02 PM, Murali Selvaraj wrote: > 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. >
You need python and perl to build but not necessarily as run time dependencies. python is used by most of the utilities (aa-logprof, aa-genprof, ...) and they are not necessary to install on a running system if all you want is enforcement. > 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. > The minimal install for the userspace is the apparmor_parser, possible libapparmor C library depending on how the apparmor_parser is linked and enablement in the init via initscript or unit file. This will get you enforcement but not the user tools or policy dev. Actually if you want to go with just precompiled policy on an image you can now get away with systemd v246 to load precompiled policy or if you can go with utils that aren't yet part of an official release yet, the aa-load utility which is a simple C program for loading policy (basically what systemd v246 is doing but for none systemd init systems). > 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. > AppArmor has minimal perl in the 2.13 and 3.0 releases. What is there is used for running tests. AppArmor 2.13 sort of supports Python 2 (I don't know the minimum version) but is better off with Python 3.3. AppArmor 3 requires Python 3. The python use in apparmor can be divided into that which is used for unit and regression testing (so build time). And run time utilities which are convenient (aa-notify) or used for profile development (aa-genprof, aa-logprof, ...) Again the only part of apparmor userspace required for policy enforcement is something in the initscript/init system to load policy into the kernel. The apparmor_parser is the traditional tool for doing this and can recompile text policy and handle caching changes. If you don't need text policy on the system you can precompile and do the load either via systemd or the aa-load utility (out of tree atm, it should land in the 3.1 release). > Do we have any details about which Yocto version (daisy or dunfell) > supports the apparmor? > I am sorry, I don't have any knowledge about this. I can look into it, but its going to be queued behind other work items that are high priority/have dead lines. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
