On 5/2/2011 3:26 PM, Sven Vermeulen wrote:
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.
I can't disagree with this more vehemently. This should not be made a
USE flag. If the user doesn't want role separations, then they should
be using unconfined users. Making this an option means users
unwittingly neuter the role separation by eliminating app, home
directory, temp directory, etc. separations.
This is a wrong band-aid fix for the cron issue. It sounds like the
cron code needs to be fixed.
--
Chris PeBenito
<[email protected]>
Developer,
Hardened Gentoo Linux
