ANN: SELinux Userspace Release

ANN: SELinux Userspace Release

[Steve Lawrence]

The SELinux userspace project has updated a release. As usual, you can
find it at http://userspace.selinuxproject.org/trac/wiki/Releases

Changes in this release include:

* Add support for optional file name in type_transition rules by Eric Paris
* Add class field in role_transition rules by Harry Ciao
* Add role attribute support by Harry Ciao
* Add file_context.subs_dist for distro specific filecon substitutions
by Daniel Walsh
* Give correct names to mount points in load_policy by Daniel Walsh
* Make sure selinux state is reported correctly if selinux is disabled
or fails to load by Daniel Walsh
* Fix crash if selinux_key_create was never called by Daniel Walsh
* Use correct color range in mcstrand by Richard Haines
* Update man pages for selinux_color_* functions by Richard Haines
* Add db_language object class support for selabel_lookup from KaiGai Kohei
* Add selinux_status_* interfaces for /selinux/status from KaiGai Kohei
* Allow filesystem names to start with a digit by James Carter
* Allow single digit module versions by Daniel Walsh

For git users, this release has been tagged 20110727 in the repository
on userspace.selinuxproject.org

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

ANN: SELinux userspace release

[Stephen Smalley]

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.

- 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]

Re: ANN: SELinux userspace release

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 5104 bytes --]

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.

> - 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-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: ANN: SELinux userspace release

[Stephen Smalley]

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.

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-leave@tycho.nsa.gov. To get help, send an email
>> containing "help" to Selinux-request@tycho.nsa.gov.
>> 
> 
> 
> 
> 
> _______________________________________________ Selinux mailing
> list Selinux@tycho.nsa.gov To unsubscribe, send email to
> Selinux-leave@tycho.nsa.gov. To get help, send an email containing
> "help" to Selinux-request@tycho.nsa.gov.
> 

Re: ANN: SELinux userspace release

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 6602 bytes --]

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-leave@tycho.nsa.gov. To get help, send an email
>>> containing "help" to Selinux-request@tycho.nsa.gov.
>>>
>>
>>
>>
>>
>> _______________________________________________ Selinux mailing
>> list Selinux@tycho.nsa.gov To unsubscribe, send email to
>> Selinux-leave@tycho.nsa.gov. To get help, send an email containing
>> "help" to Selinux-request@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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: ANN: SELinux userspace release

[Stephen Smalley]

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.

Re: ANN: SELinux userspace release

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 4723 bytes --]

On 10/14/2016 07:17 PM, Stephen Smalley wrote:
> 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.
> 
> 

This is the patch that does not fully address the issue

https://github.com/garyttierney/selinux/commit/600f20e5ea50eaac919ad8fee8987c6bdfa081e6.patch

I requires one additional "semodule -B" to make genhomedircon generate
the contexts. So it is only part of the fix. Also I haven't tested the
above patch in all scenarios (switching back and forth between the
various models)

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: ANN: SELinux userspace release

[Stephen Smalley]

On 10/14/2016 01:18 PM, Dominick Grift wrote:
> On 10/14/2016 07:17 PM, Stephen Smalley wrote:
>> 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.
>> 
>> 
> 
> This is the patch that does not fully address the issue
> 
> https://github.com/garyttierney/selinux/commit/600f20e5ea50eaac919ad8fee8987c6bdfa081e6.patch
>
>
> 
I requires one additional "semodule -B" to make genhomedircon
> generate the contexts. So it is only part of the fix. Also I 
> haven't tested the above patch in all scenarios (switching back
> and forth between the various models)

That's because it is testing the wrong policy.  As I said above, it
needs to test sepol_policydb_mls_enabled(policydb) using the policydb
passed to semanage_genhomedircon(), which is not yet the active
policy.  Doing so is also more efficient since it avoids re-loading
the policy from a file into memory.

Re: ANN: SELinux userspace release

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 5592 bytes --]

On 10/14/2016 07:28 PM, Stephen Smalley wrote:
> On 10/14/2016 01:18 PM, Dominick Grift wrote:
>> On 10/14/2016 07:17 PM, Stephen Smalley wrote:
>>> 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.
>>>
>>>
>>
>> This is the patch that does not fully address the issue
>>
>> https://github.com/garyttierney/selinux/commit/600f20e5ea50eaac919ad8fee8987c6bdfa081e6.patch
>>
>>
>>
> I requires one additional "semodule -B" to make genhomedircon
>> generate the contexts. So it is only part of the fix. Also I 
>> haven't tested the above patch in all scenarios (switching back
>> and forth between the various models)
> 
> That's because it is testing the wrong policy.  As I said above, it
> needs to test sepol_policydb_mls_enabled(policydb) using the policydb
> passed to semanage_genhomedircon(), which is not yet the active
> policy.  Doing so is also more efficient since it avoids re-loading
> the policy from a file into memory.
> 
> 

Okay if you can provide me with a patch then I can test it to confirm
that it works on my end if needed. I don't think Gary is available right
now so it might take a bit for him to rewrite it.

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: ANN: SELinux userspace release

[Stephen Smalley]

On 10/14/2016 01:28 PM, Stephen Smalley wrote:
> On 10/14/2016 01:18 PM, Dominick Grift wrote:
>> On 10/14/2016 07:17 PM, Stephen Smalley wrote:
>>> 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.
>>>
>>>
>>
>> This is the patch that does not fully address the issue
>>
>> https://github.com/garyttierney/selinux/commit/600f20e5ea50eaac919ad8fee8987c6bdfa081e6.patch
>>
>>
>>
> I requires one additional "semodule -B" to make genhomedircon
>> generate the contexts. So it is only part of the fix. Also I 
>> haven't tested the above patch in all scenarios (switching back
>> and forth between the various models)
> 
> That's because it is testing the wrong policy.  As I said above, it
> needs to test sepol_policydb_mls_enabled(policydb) using the policydb
> passed to semanage_genhomedircon(), which is not yet the active
> policy.  Doing so is also more efficient since it avoids re-loading
> the policy from a file into memory.

And that's already passed down via genhomedircon_settings_t, so you
could just do a sepol_policydb_mls_enabled(s->policydb) there instead.