On 4/2/20 6:48 AM, intrigeri wrote: > Hi, > > Alberto Mardegan (2020-04-02): >> My first question is whether this is actually doable: is the binary >> format of a cached profile independent from the machine architecture in >> which it is generated? > > I don't know about architecture portability. > > At Tails we do ship a binary, compiled policy in our live system: > > > https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-hooks/99-cache-AppArmor-policy > > https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-hooks/01-check-for-outdated-AppArmor-feature-set > > Everything I write below should be checked by people who know the > internals better than me: >
it is architecture portable. The kernel does an unpack of policy to native format on load, as well as verifications to ensure the policy is valid, there are mappings for things like signals that are different on different architectures. Policy however can be some what kernel specific. Different kernel support different features and abis. What happens will very much depend on the kernel and parser used. kernel: - tries (there are a few exceptions) to support older abis, but that means older policy won't enforce newer features that the kernel could restrict. - can not support newer abis than it knows about - can load policy with features it does not know about as long as the comply with an abi the kernel supports. Unsupported features will be ignored parser: - tries to support multiple kernel abis and features sets. - can not support features/abis that it does not know about - can downgrade some policy if policy wants to use a feature not supported in the abi ideally policy is compiled for the feature set abi of the running kernel. Older versions of apparmor only supported a single cache. 2.13 (see apparmor_parser -V) added support for multiple caches so you can have different caches for each kernel. >> Also: is the kernel version of the host machine (that is, where the >> apparmor_parser command is being run) indifferent? >> Or does it have to be apparmor-enabled? > > I don't think the kernel that compiles the policy needs to have > AppArmor enabled. > The parser by default will compile for the running kernel but it does not have to. You can specify the features file with the --features-file option. This will let you compile policy on a machine that does not have apparmor enabled on the kernel. The biggest problem is obtaining the features file for the kernel, currently this means you need to boot the target kernel (or at least one with the same feature set and abis) and run the parser to generate the cache file. Once that is done you can copy off the cache file and use that to pass it into the parser when building policy using the --features-file option. >> I see that there's a `.features` file under the cache/ directory, but >> it's not clear to me if it's related to the apparmor *userspace tools* >> features, or to the kernel. > > It's about the set of kernel features that the parser will use > in the compiled policy. For example, it avoids compiling policy > that uses features present in the kernel used at compile time, > but not by the kernel used at run time. > > yep, that is defined by the kernel feature set that the policy was compiled for. As stated above you can grab that file and pass it to the parser to force it to compile for a give feature set. If you are using apparmor 2.13 and happen to notice the options kernel-features and compile-features just ignore them. --features-files sets both of them to be the same. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
