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

> 
> Maybe we ought to just make MLS mandatory / always enabled; it is
> relied upon by various userspace components these days for MCS (e.g.
> sandbox, libvirt/svirt, openshift, etc) and most of us are only
> testing the MLS-enabled code paths since it is always enabled in
> Fedora, RHEL, and Android at least.
> 
>>
>>> - genhomedircon will generate entries for logins mapped to the
>>> default user.  Previously no entries were generated for such
>>> logins, which could lead to no matching file_contexts.homedirs
>>> entries for users with home directories outside of
>>> LU_HOMEDIRECTORY in the absence of usepasswd=True.
>>>
>>> 3) libselinux pcre2 support: - libselinux supports either pcre1
>>> or pcre2 but not both at the same time. The default remains
>>> pcre1.
>>>
>>> - To use pcre2, build libselinux and sefcontext_compile with
>>> 'make USE_PCRE2=y". You must also rebuild your file_contexts.bin
>>> files with the rebuilt sefcontext_compile.
>>>
>>> - With pcre2, file_contexts.bin is no longer
>>> architecture-neutral. The relevant architecture properties are
>>> endianness, pointer width, and PCRE2_SIZE type.  libselinux will
>>> automatically detect an architecture mismatch and ignore the
>>> stored precompiled regexes in that case, recompiling them instead
>>> at runtime.  sefcontext_compile -i will report the pcre version
>>> and architecture strings that it will include in the 
>>> file_contexts.bin file.
>>>
>>> - With pcre2, file_contexts.bin is substantially larger than for
>>> pcre1. With the Fedora policy, we see the following sizes: 383165
>>> file_contexts (text) 1507941 file_contexts.bin (binary with pcre1
>>> regexes) 8304105 file_contexts.bin (binary with pcre2 regexes)
>>>
>>> - If you know that you will be generating file_contexts.bin for a
>>> target with a different architecture string or if you do not wish
>>> to pay the additional storage cost, you can use the -r option to
>>> sefcontext_compile to omit the compiled regexes. With the Fedora
>>> policy, this yields a much smaller file: 540540 file_contexts.bin
>>> (binary omitting pcre2 regexes) You can make this the default
>>> when libsemanage invokes sefcontext_compile by adding the
>>> following stanza to semanage.conf: [sefcontext_compile] path =
>>> /usr/sbin/sefcontext_compile args = -r $@ [end] 
>>> _______________________________________________ Selinux mailing
>>> list Selinux@tycho.nsa.gov To unsubscribe, send email to
>>> selinux-le...@tycho.nsa.gov. To get help, send an email
>>> containing "help" to selinux-requ...@tycho.nsa.gov.
>>>
>>
>>
>>
>>
>> _______________________________________________ Selinux mailing
>> list Selinux@tycho.nsa.gov To unsubscribe, send email to
>> selinux-le...@tycho.nsa.gov. To get help, send an email containing
>> "help" to selinux-requ...@tycho.nsa.gov.
>>
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
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