selinux: update eclass, libsepol to 3.1 and semodule-utils

[tormath1]

(this PR superseeds #66)

• add a new package semodule-utils with temporary patch to avoid conflict with policycoreutils-2.4: this packages provide the same files
• upgrade libsepol to 3.1 as it's required to upgrade libselinux
• upgrade selinux-policy-2 eclass and patch it (https://bugs.gentoo.org/794682)

basically we can provide patches to a SELinux policies in the ebuild using the POLICY_PATCH variable but it was failing with:
[[ ${#files[@]} -eq 0 ]] && die "No *.{patch,diff} files in directory ${f}

Digging into the eclass, we have the following:
[[ -n ${POLICY_PATCH[*]} ]] && eapply -d "${S}/refpolicy/policy/modules" "${POLICY_PATCH[@]}"
so it seems the -d "${S}/refpolicy/policy/modules" is interpreted as "apply any patches you find in this repository" not sure why... if the it's confirmed by the gentoo-hardened let's push the patch upstream if not, let's move this eclass to ::coreos-overlay.

How to use

emerge-amd64-usr libsepol semodule-utils

Testing done

• booting the qemu instance
• kola tests (kola/docker: add selinux test flatcar/mantle#177)
• Jenkins CI: http://jenkins.infra.kinvolk.io:8080/job/os/job/manifest/2927/cldsv/

[dongsupark]

Looks good in general.

Nits:

[dongsupark]

If semodule-utils requires Flatcar changes, then why don't we move it to coreos-overlay?

[tormath1]

That's right - it's an edge case actually: starting from policycoreutils-2.7, semodule-utils becomes a single entity; see this commit: SELinuxProject/selinux@c9c97d6.

In the current way we upgrade the things, semodule-utils needs to be installed after the policycoreutils upgrade - otherwise semodule-utils-3.1 will collide with some files provided by policycoreutils-2.4.

This blocker allows portage to first upgrade policycoreutils then install semodule-utils.

We can certainly move semodule-utils to ::coreos-overlay but we would need to move it back in ::portage-stable once the upgrade done. :)