[apparmor] socket mediation patch

[John Johansen]

On 04/01/2018 08:04 PM, Goldwyn Rodrigues wrote:
> Hi,
> 
> This is in reference to the socket mediation patch (commit id
> 56974a6fcfef69ee0825bd66ed13e92070ac5224) in apparmor-next branch.
> Why should there be an ABI change for this? Why should the SFS directory
> be called network_v8 as opposed to just network? Is it because of
> network directories earlier/distro kernels? How does it affect userspace
> utils?
> 
> 

Hey Goldwyn,

this has been discussed a few times in the IRC channel and other
places but I guess it has never been discussed in sufficient detail on
the ml.

Linus reverted the networking patch in 4.14. The only way to come
close to meeting the requirements laid out then was to change the ABI
of the networking patch so that old userspaces will not generate
networking rules and cause breakage for kernel developers.

The new abi on the patch however is not sufficient as just introducing
the new abi to the parser will lead to the same problem that lead to
the revert. To fix this userspace must transition to policy
versioning, which has seen some discussion on the list.

What this means for the userspace tools is they will continue to work
with the old networking abi, but older versions of the tools will
never work with the new abi. Support for the new abi will be
introduced in apparmor 3.0 with policy versioning, and there will
never be an upstream patch to allow the apparmor 2.x userspace to
support the new abi; as the risk to the projects ability to land new
features upstream is too great.

If you are a distro that has carried the old networking patch there
shouldn't be any need to drop it at this time as that will lead to a
regression in the distro. Instead upstream kernels going forward will
be limited to the pre-networking abi on releases with an apparmor 2.x
userspace. A kernel patch adding support for the old networking abi to
newer kernels is possible, and would allow distros to support both old
and new networking abis during a transition period, at the cost of
continuing to carry a patch that will not go upstream (Eg ubunut might
want to use it for their HWE kernels where a new kernel is brought
back to an older release).

Going forward policy development will change some what. If not using
policy pinning (almost everyone doesn't) policy will not automatically
get policy recompiled for new kernel abis which can result in denials
and failures that lead to the 4.14 revert. Instead policy will be
compiled using its embedded policy version, and loaded to the kernel
using that. If an author wants to update policy to use new features,
they will need to update the policy to declare that policy as using
the particular abi and then the policy can be built and loaded into
the kernel.

This may seem inconvenient, it can be for policy authors during a
development cycle where you may want bug reports and to be updating
policy to a new abi. But it will lead to a better experience for
users, application developers who are shipping policy as part of their
package, and distros who want to hold policy to a supported abi over
the life of the release.