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
