On 02/18/2018 01:42 AM, Vincas Dargis wrote: > On 2/17/18 8:54 PM, John Johansen wrote: >> On 02/17/2018 10:11 AM, Vincas Dargis wrote: >>> That would be fast... I will need to research how to run latest AppArmor or >>> my (virtual?) machine to work on thought. >> >> As long as you don't need a new libapparmor (you shouldn't for these >> patches) either grab a tarball or fresh checkout >> >> make sure you have the builddeps, >> >> sudo apt-get build-dep apparmor >> >> cd into the parser/ dir and do >> >> make USE_SYSTEM=1 >> >> now you can use the built parser by doing >> >> ./apparmor_parser >> >> or you can do a >> sudo make install >> >> to install it to the system > > Thanks. > > Newer apparmor_parser will not need any newer kernel patches? > > For this feature no, this can all be done entirely in userspace.
And in general no, we try to keep the kernel and userspace some what independent, that is the kernel supports older userspace abis even as it adds new features, it is mostly compatible with a 2009 userspace and policy except there have been some changes in the kernel (none appparmor) that break older policy, but it is possible to update the older policy to work with a modern kernel. Similarly the apparmor userspace supports kernels from the 2.6 era. Its the policy and userspace that need to largely move in lock step, because as new features get added to policy the parsing of policy needs to know how to handle the new feature. New policy + new userspace on older kernels is handled by downgrading rules unless configured to fail. The proposal to allow the error and warn statement begin with a # will allow older userspaces to ignore them by treating them as a comment, so the policy can even be applied to older userspaces, it just won't result in an error or warning message. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
