On 10/14/2016 12:20 PM, Dominick Grift wrote:
> On 10/14/2016 06:15 PM, Stephen Smalley wrote:
>> On 10/14/2016 12:02 PM, Dominick Grift wrote:
>>> On 10/14/2016 05:55 PM, Stephen Smalley wrote:
>>>> The 2016-10-14 / 2.6 release for the SELinux userspace is
>>>> now available at: 
>>>> https://github.com/SELinuxProject/selinux/wiki/Releases
>>>> This has been tagged as 20161014 in the git repository.
>>>> Below are some notes on this release for packagers of the 
>>>> SELinux userspace.  Please see the individual ChangeLog files
>>>> for a detailed list of changes.
>>>> 1) sepolicy converted to setools4: - sepolicy and its users
>>>> now depend on setools4 instead of setools3.
>>>> - Please convert any remaining users of setools3 to setools4 
>>>> since setools3 is no longer being developed.
>>>> 2) genhomedircon enhancements and behavior changes: - 
>>>> genhomedircon supports the %{USERID} template for
>>>> substituting the user's uid. %{USERNAME} has also been added
>>>> as a new template for substituting the user's username.  The
>>>> USER template is still supported for backward compatibility
>>>> but is deprecated.
>>>> - genhomedircon supports generating home directory contexts
>>>> for login mappings using the %group syntax.  This may produce
>>>> an error if the user belongs to multiple groups specified in
>>>> the login mapping, which can be resolved by adding an
>>>> explicit mapping for the user to override the group-based
>>>> mapping.
>>>> - genhomedircon will fully replace the SELinux user and
>>>> range fields in each templated security context rather than
>>>> only substituting for the hardcoded strings "system_u" and
>>>> "s0".  As a side effect, genhomedircon no longer has special
>>>> handling of "system_u" and will therefore trigger a warning
>>>> if there is a "system_u" entry in seusers:
>>>> libsemanage.add_user: user system_u not in password file This
>>>> warning is not fatal, but it would be preferable to remove
>>>> system_u from the seusers file. See 
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1378204
>>>> - genhomedircon will replace the role field in each
>>>> templated security context with the user prefix for the user
>>>> if the user prefix is the identifier of a role valid for the
>>>> given user, or if it is "object_r". This enables configuring
>>>> RBACSEP (i.e. role-based separation of user home directories)
>>>> in policy.  If the user prefix is not a valid role, then
>>>> genhomedircon will leave the role field unmodified as
>>>> before.
>>> An issue was reported about genhomedircon with standard policy 
>>> model (non-mls), where no contexts were generated.
>>> I was able to reproduce this issue, and Gary produced a patch
>>> to fix this. However the patch does not fully address the
>>> issue, as it requires that one runs an additional semodule -B
>>> to rerun genhomedircon. genhomedircon does not generate the
>>> contexts the first time around.
>> Hmm..reported to whom, and where did this discussion take place?
>> I have seen nothing on the list.  Would have been helpful to
>> have reported it on the -rc releases.
> Someone using gentoo-hardened encountered the issue, and gentoo 
> maintainer told Gary about it on IRC. Two day's ago, with a delay,
> I set out to reproduce the issue to confirm the bug. I was planning
> to report this on the list but: I was not expecting a release this
> soon, and I was hoping for a revisited patch soon but it obviously
> delayed.
> So only two day's ago the bug was confirmed. We should have
> reported then but we didn't

Since I haven't seen the patch, I can't comment on it.  I would think
one could simply test sepol_policydb_mls_enabled(policydb) in
semanage_genhomedircon() to determine whether MLS is enabled, and then
pass that result down as appropriate so that the underlying code could
handle the MLS-disabled case correctly.

Selinux mailing list
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Reply via email to