[gentoo-hardened] SELinux base policy -r13 in overlay, adds "ubac" USE flag

[Sven Vermeulen <sven.vermeulen@siphos.be>]

Hi folks,

sec-policy/selinux-base-policy-2.20101213-r13 is pushed to the overlay. The
most notable change here is that the ebuild now uses a local USE flag "ubac"
which enables User Based Access Control within the policy.

Previously, UBAC was enabled but could not be disabled. However, most other
distributions have disabled UBAC and are waiting for the RBAC model within
SELinux to improve. Although this work is on the way, it isn't there yet and
I personally do not dislike the UBAC idea.

However, we have at least one issue that was difficult to debug due to UBAC:
the vixie-cron "ENTRYPOINT FAILED" messages. Apparently, vixie-cron checks
the privileges on the users' crontab. However, if the root crontab wasn't
created by a console-logged-on root user (SELinux identity "root") but
through a su(do)'ed user (SELinux identity "staff_u" most likely), then the
UBAC kicked in and didn't allow cron to work.

Although the solution is simple (either create the root cronjob through the
root SELinux identity, or change the SELinux identity of the crontab file to
"root" afterwards), disabling UBAC also works here.

We had a small discussion on #gentoo-hardened and a larger discussion on
#selinux about UBAC. Nice as we are, we of course do not want to force any
choice upon our users, so we decided to see if we can work with a USE flag
to switch the UBAC functionality. The only remaining discussion is if we
want to have this USE flag enabled by default, or not. If we want to enable
it by default, we should work with the pending upgrade of the profiles to do
so. But imo, we do not really have to enable it by default.

Long story short: USE="ubac" emerge selinux-base-policy to enable UBAC.

Other changes are an update of the Portage support for live ebuilds, -r12
added portage_svnsrc_t but I forgot that we also have git-src and cvs-src
(thanks to PeBenito for noticing). So we now use portage_srcrepo_t. I also
added some elogs to inform the users generally about what he might want to
do:
 * Updates on policies might require you to relabel files. If you, after
 * installing new SELinux policies, get 'permission denied' errors, 
 * relabelling your system using 'rlpkg -a -r' might resolve the issues.

There's one point that I'm not sure how to handle, and that's what to do
when the new SELinux policy fails to load. Currently, we ignore this
failure, but then users aren't informed about this. But if we don't ignore,
they will have it more difficult to fix the problem as the new base.pp is
removed from the system (so they cannot run "semodule -b base.pp" to (re)try
and get the proper failure messages.

I'm thinking about not ignoring the failure but making sure that the
build logs of the (failed) install contains all information needed to fix.

Oh darn, almost a full page of rambling, I'll shut up now.

	Sven Vermeulen