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

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

[Sven Vermeulen]

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

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

[klondike]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

El 02/05/11 21:26, Sven Vermeulen escribió:
> Oh darn, almost a full page of rambling, I'll shut up now.
>
> 	Sven Vermeulen
Sven, I think I speak in the name of the whole team saying that your
ramblings are more than welcome after all the hard work you are doing on
SELinux :D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Chris PeBenito]

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
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux

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

[Sven Vermeulen]

On Mon, May 09, 2011 at 09:25:25AM -0400, Chris PeBenito wrote:
> 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.

With the current way of working, in my opinion it is a matter of
documenting the differences when you run with SELinux (i.e. have information
on Cron + SELinux, Postfix + SELinux, Apache + SELinux, ...). Not separate
documents for each, but a general sum-up of those systems where additional
information can be warranted (if not just to describe the types and perhaps
booleans that users might be interested in).

You're mentioning role separation, but the current method uses SELinux user
separation. When role separation is in effect, I agree wholeheartedly -
checking the file's role (sysadm_r then) and security context role (sysadm_r
then too) will update the situation and makes a lot more sense.

Fixing the code is not that obvious, but not impossible either. It depends a
bit on what the requirements are that we have on vixie-cron with SELinux
integration. Again, I prefer documenting these things, but there are also
code-wise possibilities.

With SELinux user separation, we can make separate crontabs depending on
the SELinux user (so instead of "root" it could become "root+root" versus
"root+staff_u", or make subdirectories based on the SELinux user) but that
is not an obvious fix (it requires a lot more patches than we currently have
in place for vixie-cron) which might not be necessary anymore when true
role-based access controls can be put in place.

Another possibility would be to set the default context from cron to the
users' context (so for root, it would become root:sysadm_r:sysadm_t). As
sysadm_t is exempt from UBAC, this would allow the root cronjobs to start.
But then we're "circumventing" UBAC, which is not really what we are looking
for.

There are many other ways to handle this situation too - I'm leaving that to
the colorful imagination of the developers ;-)

Anyhow, about the USE="ubac" functionality. I'm personally never going to
disable UBAC on my systems (never had any issues with it) but I can imagine
that some people would like to disable it (just like some people might be
interested in a non-hardened SELinux profile) so not providing the means to
switch it off (refpolicy has it as a configurable setting, so why not) might
be a bit harsh. But I wouldn't mind having USE="ubac" forced on by the
SELinux profiles (so a user would need to use.force it in their local profile
override location). Is that a situation you can live with?

Wkr,
	Sven Vermeulen