All of lore.kernel.org
 help / color / mirror / Atom feed
* Role attributes in traditional language constraints
@ 2021-03-10 17:09 Christian Göttsche
  2021-03-10 18:08 ` James Carter
  0 siblings, 1 reply; 2+ messages in thread
From: Christian Göttsche @ 2021-03-10 17:09 UTC (permalink / raw)
  To: SElinux list

Hi list,

I am using in my RefPolicy based policy constraints containing role-attributes:

    attribute_role unpriv_roles;
    ...
    constrain ...
        r1 != unpriv_role

This worked fine so far and the language specification [1][2] permits
the usage of type attributes (by using them in the examples) and
states not differences between `t1 op names` and `r1 op names`.

Today I debugged a crash of seinfo(1) on generated binary policies of mine.
`seinfo path/to/build/policy --constrain` segfaults at [3], when run
on a build binary policy.
These binary policies are generated by the RefPolicy target `make
validate`, running either semodule_link(8) and semodule_expand(8)
(modular build) or checkpolicy(8) (monolithic build).

Running `seinfo --constrain`, using the currently loaded kernel
policy, works fine and shows the expanded roles in the according
constrain (e.g. `r1 != { user_r guest_r ... }`).

On further testing I noticed that on Fedora 34 with libsepol 3.2
building such policies fails entirely:

    ...
    Validating policy file contexts.
    libsepol.validate_constraint_nodes: Invalid constraint expr
    libsepol.validate_class_datum: Invalid class datum
    libsepol.validate_datum_arrays: Invalid datum arrays
    libsepol.validate_policydb: Invalid policydb
    libsepol.sepol_set_policydb_from_file: can't read binary policy: Success
    Error reading policy tmp/policy.bin: Success
    make: *** [Rules.modular:215: validate] Error 255

This seems to be caused by [4].

From my point of view this is a regression:
Role-attributes in constraints worked prior libsepol 3.2, work in CIL
and are not explicitly disallowed by the language specification.
`validate_constraint_nodes()`[5] should accept attribute_role identifiers.

To fix the original seinfo crash, I'd like to ask whether setools
should accept role-attribute identifiers in compiled binary policies,
or if semodule_expand(8) and checkpolicy(8) should expand them at
build-time (currently they are expanded at load-time (load_policy(8)).

Best regards,
    Christian Göttsche


[1]: https://selinuxproject.org/page/ConstraintStatements
[2]: https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#constraint-statements
[3]: https://github.com/SELinuxProject/setools/blob/master/setools/policyrep/role.pxi#L34
[4]: https://github.com/SELinuxProject/selinux/commit/0861c659b59cb106bad1b1d0c9f511a7140a1023
[5]: https://github.com/SELinuxProject/selinux/blob/master/libsepol/src/policydb_validate.c#L170

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Role attributes in traditional language constraints
  2021-03-10 17:09 Role attributes in traditional language constraints Christian Göttsche
@ 2021-03-10 18:08 ` James Carter
  0 siblings, 0 replies; 2+ messages in thread
From: James Carter @ 2021-03-10 18:08 UTC (permalink / raw)
  To: Christian Göttsche; +Cc: SElinux list

On Wed, Mar 10, 2021 at 12:10 PM Christian Göttsche
<cgzones@googlemail.com> wrote:
>
> Hi list,
>
> I am using in my RefPolicy based policy constraints containing role-attributes:
>
>     attribute_role unpriv_roles;
>     ...
>     constrain ...
>         r1 != unpriv_role
>

Role attributes in constraint expressions are not currently expanded.
I was already working on a patch to expand them. I will probably get
that patch out before the end of the day.

> This worked fine so far and the language specification [1][2] permits
> the usage of type attributes (by using them in the examples) and
> states not differences between `t1 op names` and `r1 op names`.
>
> Today I debugged a crash of seinfo(1) on generated binary policies of mine.
> `seinfo path/to/build/policy --constrain` segfaults at [3], when run
> on a build binary policy.
> These binary policies are generated by the RefPolicy target `make
> validate`, running either semodule_link(8) and semodule_expand(8)
> (modular build) or checkpolicy(8) (monolithic build).
>
> Running `seinfo --constrain`, using the currently loaded kernel
> policy, works fine and shows the expanded roles in the according
> constrain (e.g. `r1 != { user_r guest_r ... }`).
>

I don't know how that works. Something else must be going on.

With the following policy, using the Fedora 32 versions of checkpolicy
and seinfo leads to a segfault of seinfo.
class CLASS1
sid kernel
class CLASS1 { PERM1 }
type TYPE1;
allow TYPE1 self : CLASS1 PERM1;
attribute_role ROLE_ATTR1;
role ROLE1;
roleattribute ROLE1 ROLE_ATTR1;
role ROLE1 types TYPE1;
user USER1 roles ROLE1;
constrain CLASS1 { PERM1 } ( r1 == ROLE_ATTR1 );
sid kernel USER1:ROLE1:TYPE1

With the following CIL policy, using the Fedora 32 versions of secilc
and seinfo leads to a segfault of seinfo.
(class CLASS1 (PERM1))
(classorder (CLASS1))
(sid kernel)
(sidorder (kernel))
(category CAT)
(categoryorder (CAT))
(sensitivity SENS)
(sensitivityorder (SENS))
(sensitivitycategory SENS (CAT))
(type TYPE1)
(allow TYPE1 self (CLASS1 (PERM1)))
(roleattribute ROLE_ATTR1)
(roleattributeset ROLE_ATTR1 (ROLE1))
(role ROLE1)
(roletype ROLE1 TYPE1)
(user USER1)
(userrole USER1 ROLE1)
(userlevel USER1 (SENS))
(userrange USER1 ((SENS)(SENS (CAT))))
(constrain (CLASS1 (PERM1)) (eq r1 ROLE_ATTR1))
(sidcontext kernel (USER1 ROLE1 TYPE1 ((SENS)(SENS))))

> On further testing I noticed that on Fedora 34 with libsepol 3.2
> building such policies fails entirely:
>
>     ...
>     Validating policy file contexts.
>     libsepol.validate_constraint_nodes: Invalid constraint expr
>     libsepol.validate_class_datum: Invalid class datum
>     libsepol.validate_datum_arrays: Invalid datum arrays
>     libsepol.validate_policydb: Invalid policydb
>     libsepol.sepol_set_policydb_from_file: can't read binary policy: Success
>     Error reading policy tmp/policy.bin: Success
>     make: *** [Rules.modular:215: validate] Error 255
>
> This seems to be caused by [4].
>

This is correctly finding that the role ebitmap in the constraint
expression is referencing a non-existent role which is what happens
now when a role attribute is used in a constraint. As far as I can
tell, it was not working before the policydb validation patch.

> From my point of view this is a regression:
> Role-attributes in constraints worked prior libsepol 3.2, work in CIL
> and are not explicitly disallowed by the language specification.
> `validate_constraint_nodes()`[5] should accept attribute_role identifiers.
>
> To fix the original seinfo crash, I'd like to ask whether setools
> should accept role-attribute identifiers in compiled binary policies,
> or if semodule_expand(8) and checkpolicy(8) should expand them at
> build-time (currently they are expanded at load-time (load_policy(8)).
>

That role attributes don't work in a constraint expression is a bug
and I am working on a fix.

Thanks for the report,
Jim


> Best regards,
>     Christian Göttsche
>
>
> [1]: https://selinuxproject.org/page/ConstraintStatements
> [2]: https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#constraint-statements
> [3]: https://github.com/SELinuxProject/setools/blob/master/setools/policyrep/role.pxi#L34
> [4]: https://github.com/SELinuxProject/selinux/commit/0861c659b59cb106bad1b1d0c9f511a7140a1023
> [5]: https://github.com/SELinuxProject/selinux/blob/master/libsepol/src/policydb_validate.c#L170

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-03-10 18:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 17:09 Role attributes in traditional language constraints Christian Göttsche
2021-03-10 18:08 ` James Carter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.