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: > 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. > 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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
