SELinux Userspace Release: 20140826-rc6

SELinux Userspace Release: 20140826-rc6

[Steve Lawrence]

The sixth release candidate for the next release of SELinux Userspace
[1] is now available. The tarballs have been built and can be downloaded
from the Releases wiki page [2]. Changes since rc5 include:

- updates to pp2cil compiler to mimic 'requires' in CIL, fixing a bug
that prevented a small set of optional blocks from being correctly
disabled [4]
- updates to pp2cil compiler to correctly scope type aliases, fixing a
bug that causes errors if a type alias referenced a type in a disabled
optional block [5]

As with the previous rc, action after installing the release candidate
is required to migrate the policy store from /etc/selinux to
/var/lib/selinux if it has not already been migrated. Detailed
information about this process can be found on the Policy Store
Migration wiki page [3].

Also, because the pp2cil compiler has been updated, any cached CIL
modules must be rebuilt. This can be done with the --ignore-module-cache
semodule option.

Please give this a test and let us know if you find any problems.

Thanks,
- Steve

[1] https://github.com/SELinuxProject/selinux
[2] https://github.com/SELinuxProject/selinux/wiki/Releases
[3] https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration
[4] http://marc.info/?l=selinux&m=141537621807753&w=2
[5] http://marc.info/?l=selinux&m=141537664108369&w=2

Re: SELinux Userspace Release: 20140826-rc6

[Sven Vermeulen]

On Wed, Nov 12, 2014 at 2:50 PM, Steve Lawrence <slawrence@tresys.com> wrote:
> The sixth release candidate for the next release of SELinux Userspace
> [1] is now available. The tarballs have been built and can be downloaded
> from the Releases wiki page [2]. Changes since rc5 include:
>
> - updates to pp2cil compiler to mimic 'requires' in CIL, fixing a bug
> that prevented a small set of optional blocks from being correctly
> disabled [4]
> - updates to pp2cil compiler to correctly scope type aliases, fixing a
> bug that causes errors if a type alias referenced a type in a disabled
> optional block [5]
>
> As with the previous rc, action after installing the release candidate
> is required to migrate the policy store from /etc/selinux to
> /var/lib/selinux if it has not already been migrated. Detailed
> information about this process can be found on the Policy Store
> Migration wiki page [3].
>
> Also, because the pp2cil compiler has been updated, any cached CIL
> modules must be rebuilt. This can be done with the --ignore-module-cache
> semodule option.
>
> Please give this a test and let us know if you find any problems.

Hi Steve

As discussed on #selinux a few minutes ago, one of the issues we got
(and I think it is also in rc5, but I'm not sure why I didn't catch
that earlier - might forgot rebuilds or reloads or so) is that some of
the role type assignments (like "role staff_r types xauth_t") which
should result in CIL's "(roletype staff_r xauth_t)" are not being
generated (and hence not used either). As a result, many domains are
not able to transition to other domains (with the "invalid context"
messages in the audit logs as a result).

If you do find this issue and a fix, I can happily apply just this so
we can do more testing before a next version bump.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc6

[Sven Vermeulen]

On Wed, Nov 12, 2014 at 2:50 PM, Steve Lawrence <slawrence@tresys.com> wrote:
> The sixth release candidate for the next release of SELinux Userspace
> [1] is now available.
[...]
> Please give this a test and let us know if you find any problems.

Hi Steve & SELinux folks

With 2.4, I noticed that the user mapping now includes the "object_r" role:

# semanage user -l

                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range
SELinux Roles

root            user       s0         s0-s0:c0.c1023
object_r staff_r sysadm_r
staff_u         user       s0         s0
staff_r sysadm_r system_r
sysadm_u        user       s0         s0-s0:c0.c1023
object_r sysadm_r
system_u        user       s0         s0-s0:c0.c1023
object_r system_r
unconfined_u    user       s0         s0-s0:c0.c1023
object_r unconfined_r
user_u          user       s0         s0
object_r user_r

With 2.3, the "object_r" role was not in the list of allowed roles.

Now, I tried to remove the "object_r" role from one of my test VMs but
that totally screwed up the image (system froze, and reboot failed).
I'm not sure if I'm allowed to remove it or not now. If I should, I'll
investigate it further and see if I can get denials or other
information from it.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc6

[Dominick Grift]

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

On Mon, Nov 24, 2014 at 11:15:42AM +0100, Sven Vermeulen wrote:

> 
> Now, I tried to remove the "object_r" role from one of my test VMs but
> that totally screwed up the image (system froze, and reboot failed).
> I'm not sure if I'm allowed to remove it or not now. If I should, I'll
> investigate it further and see if I can get denials or other
> information from it.

object_r should be associated with all security identitiers i believe (including selinux user identities)

What you are seeing is expected, and you should not try to remove it

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: SELinux Userspace Release: 20140826-rc6

[Sven Vermeulen]

On Mon, Nov 24, 2014 at 12:26 PM, Dominick Grift <dac.override@gmail.com> wrote:
>> Now, I tried to remove the "object_r" role from one of my test VMs but
>> that totally screwed up the image (system froze, and reboot failed).
>> I'm not sure if I'm allowed to remove it or not now. If I should, I'll
>> investigate it further and see if I can get denials or other
>> information from it.
>
> object_r should be associated with all security identitiers i believe (including selinux user identities)
>
> What you are seeing is expected, and you should not try to remove it

The downside is that with the 2.3 utilities, mentioning "object_r" fails:

~# semanage user -m -R "object_r sysadm_r system_r" root
ValueError: object_r must be an SELinux role:
Valid roles: staff_r, sysadm_r, system_r, unconfined_r, user_r

But with 2.4, not mentioning "object_r" while manipulating the user
definition results in the failure.

That makes it confusing for administrators that need to manage SELinux
systems where one set uses 2.3 userspace and another uses 2.4.
Especially those that use configuration management utilities like salt
or puppet, as those will now need to add in logic to find out if
"object_r" is already in the list or not and update accordingly.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc6

[Sven Vermeulen]

On Mon, Nov 24, 2014 at 4:15 PM, Sven Vermeulen
<sven.vermeulen@siphos.be> wrote:
> On Mon, Nov 24, 2014 at 12:26 PM, Dominick Grift <dac.override@gmail.com> wrote:
>>> Now, I tried to remove the "object_r" role from one of my test VMs but
>>> that totally screwed up the image (system froze, and reboot failed).
>>> I'm not sure if I'm allowed to remove it or not now. If I should, I'll
>>> investigate it further and see if I can get denials or other
>>> information from it.
>>
>> object_r should be associated with all security identitiers i believe (including selinux user identities)
>>
>> What you are seeing is expected, and you should not try to remove it
>
> The downside is that with the 2.3 utilities, mentioning "object_r" fails:
>
> ~# semanage user -m -R "object_r sysadm_r system_r" root
> ValueError: object_r must be an SELinux role:
> Valid roles: staff_r, sysadm_r, system_r, unconfined_r, user_r
>
> But with 2.4, not mentioning "object_r" while manipulating the user
> definition results in the failure.
>
> That makes it confusing for administrators that need to manage SELinux
> systems where one set uses 2.3 userspace and another uses 2.4.
> Especially those that use configuration management utilities like salt
> or puppet, as those will now need to add in logic to find out if
> "object_r" is already in the list or not and update accordingly.

I just did another test, now with custom roles. I noticed that the
object_r assigned during the migration isn't done on all SELinux user
mappings?

Before migration:
                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range
SELinux Roles

root            user       s0         s0
sysadm_r system_r
staff_u         user       s0         s0
staff_r sysadm_r system_r
sysadm_u        user       s0         s0
sysadm_r system_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
testrole_u      user       s0         s0                             testrole_r
unconfined_u    unconfined s0         s0-s0:c0.c1023
unconfined_r
user_u          user       s0         s0                             user_r

After migration:
                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range
SELinux Roles

root            user       s0         s0
sysadm_r system_r
staff_u         user       s0         s0
staff_r sysadm_r system_r
sysadm_u        user       s0         s0
sysadm_r system_r
system_u        user       s0         s0-s0:c0.c1023
object_r system_r
testrole_u      user       s0         s0                             testrole_r
unconfined_u    user       s0         s0-s0:c0.c1023
object_r unconfined_r
user_u          user       s0         s0
object_r user_r

So in this case, object_r is assigned (during migration) to system_u,
unconfined_u and user_u, but not to root, staff_u, sysadm_u and
testrole_u.

Those roles still work though. Is showing object_r in the "SELinux
Roles" part cosmetic perhaps?

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc6

[Dominick Grift]

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

On Thu, Nov 27, 2014 at 01:23:13PM +0100, Sven Vermeulen wrote:
> 
> So in this case, object_r is assigned (during migration) to system_u,
> unconfined_u and user_u, but not to root, staff_u, sysadm_u and
> testrole_u.
> 
> Those roles still work though. Is showing object_r in the "SELinux
> Roles" part cosmetic perhaps?
> 

Strange ... as far as i know object_r needs to be associated with everyone

Is your output of seinfo -xu consistent with that of semanage user (as far as roles associated with identities is concerned)?

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: SELinux Userspace Release: 20140826-rc6

[Sven Vermeulen]

On Thu, Nov 27, 2014 at 6:38 PM, Dominick Grift <dac.override@gmail.com> wrote:
> On Thu, Nov 27, 2014 at 01:23:13PM +0100, Sven Vermeulen wrote:
>>
>> So in this case, object_r is assigned (during migration) to system_u,
>> unconfined_u and user_u, but not to root, staff_u, sysadm_u and
>> testrole_u.
>>
>> Those roles still work though. Is showing object_r in the "SELinux
>> Roles" part cosmetic perhaps?
>>
>
> Strange ... as far as i know object_r needs to be associated with everyone
>
> Is your output of seinfo -xu consistent with that of semanage user (as far as roles associated with identities is concerned)?

It is not. seinfo -xu shows object_r to be associated with *all* roles
(as you suggested) whereas the "semanage user -l" output shows it
missing with a few of them.

This is the only inconsistency though - the rest of the output does match.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc6

[Steve Lawrence]

On 11/27/2014 03:14 PM, Sven Vermeulen wrote:
> On Thu, Nov 27, 2014 at 6:38 PM, Dominick Grift <dac.override@gmail.com> wrote:
>> On Thu, Nov 27, 2014 at 01:23:13PM +0100, Sven Vermeulen wrote:
>>>
>>> So in this case, object_r is assigned (during migration) to system_u,
>>> unconfined_u and user_u, but not to root, staff_u, sysadm_u and
>>> testrole_u.
>>>
>>> Those roles still work though. Is showing object_r in the "SELinux
>>> Roles" part cosmetic perhaps?
>>>
>>
>> Strange ... as far as i know object_r needs to be associated with everyone
>>
>> Is your output of seinfo -xu consistent with that of semanage user (as far as roles associated with identities is concerned)?
> 
> It is not. seinfo -xu shows object_r to be associated with *all* roles
> (as you suggested) whereas the "semanage user -l" output shows it
> missing with a few of them.
> 
> This is the only inconsistency though - the rest of the output does match.
> 

First of all, sorry about the delayed response.

I agree that this inconsistency is a problem. It looks like the problem
is in CIL. Dominick is right in that object_r is implicitly associated
with all roles, but CIL sets a bit to make the user/object_r
association, even though it is unnecessary. This appears to have caused
the behavior change in some of the tools. We just need to special case
object_r to not make the association and rely on the implied association
existing. This has been fixed in CIL [1] and will be part of the next
release candidate.

- Steve

[1]
https://github.com/SELinuxProject/cil/commit/08520e91db86bdbb8ce393afa35c1465bdc7f63b