hierarchy_check_constraints() needs reworks?

hierarchy_check_constraints() needs reworks?

[KaiGai Kohei]

I found out that hierarchy_check_constraints() in libsepol
does not work correctly, as follows:

---- example: foo.te ----
module foo 1.0;

require {
        class file { read write getattr setattr ioctl };
};

type src;
type src.child;
type tgt;

allow src       tgt : file { read write };
allow src.child tgt : file { read write getattr setattr };
----------
[root@fedora9 kaigai]# checkmodule -m -M foo.te -o foo.mod
checkmodule:  loading policy configuration from foo.te
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 8) to foo.mod
[root@fedora9 kaigai]# /usr/sbin/semodule -i foo.pp
[root@fedora9 kaigai]#

The "foo.te" can make a hierarchy constraint violation, but we got
no assertion in this case.

I inject several printf()s to show internal state, and it shows me
the given p->te_avtab is empty, so no checks are applied. :-(
Now, I'm tracing it more.


In addition, I found two more potential matter in this code.

The first one is lack of checks for permissions via attribute.
When a child domain has an attribute which does not applied to
the parent one, the child can have wider permissions that its
parent.
I think any attribute attached to child domain also have to be
attached to the parent domain.
(I guess it derived from legacy attribute implementation.)

The later one is dependencies to the state of boolean.
Hierarchy constraint allows a child domain to have permissions
which are enabled for the parent, only if specific boolean is
turned on. It potentially makes a situation that child domain
has wider permissions.
I think it is difficult to check in the policy toolchain, so
checks on an avc entry creation is better way.

Any comment?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

Re: hierarchy_check_constraints() needs reworks?

[Stephen Smalley]

On Thu, 2008-07-24 at 14:38 +0900, KaiGai Kohei wrote:
> I found out that hierarchy_check_constraints() in libsepol
> does not work correctly, as follows:
> 
> ---- example: foo.te ----
> module foo 1.0;
> 
> require {
>         class file { read write getattr setattr ioctl };
> };
> 
> type src;
> type src.child;
> type tgt;
> 
> allow src       tgt : file { read write };
> allow src.child tgt : file { read write getattr setattr };
> ----------
> [root@fedora9 kaigai]# checkmodule -m -M foo.te -o foo.mod
> checkmodule:  loading policy configuration from foo.te
> checkmodule:  policy configuration loaded
> checkmodule:  writing binary representation (version 8) to foo.mod
> [root@fedora9 kaigai]# /usr/sbin/semodule -i foo.pp

Check /etc/selinux/semanage.conf to see if you have expand-check=1 set;
otherwise, there is no hierarchy checking or neverallow checking
occurring there.  Disabled by default in Fedora due to the overhead and
the view that it should be handled at policy build time rather than
insertion time.  refpolicy has a make validate target that runs
semodule_link followed by semodule_expand manually.

> [root@fedora9 kaigai]#
> 
> The "foo.te" can make a hierarchy constraint violation, but we got
> no assertion in this case.
> 
> I inject several printf()s to show internal state, and it shows me
> the given p->te_avtab is empty, so no checks are applied. :-(
> Now, I'm tracing it more.
> 
> 
> In addition, I found two more potential matter in this code.
> 
> The first one is lack of checks for permissions via attribute.
> When a child domain has an attribute which does not applied to
> the parent one, the child can have wider permissions that its
> parent.
> I think any attribute attached to child domain also have to be
> attached to the parent domain.
> (I guess it derived from legacy attribute implementation.)
> 
> The later one is dependencies to the state of boolean.
> Hierarchy constraint allows a child domain to have permissions
> which are enabled for the parent, only if specific boolean is
> turned on. It potentially makes a situation that child domain
> has wider permissions.
> I think it is difficult to check in the policy toolchain, so
> checks on an avc entry creation is better way.
> 
> Any comment?
> 
> Thanks,


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

RE: hierarchy_check_constraints() needs reworks?

[Joshua Brindle]

KaiGai Kohei wrote:
> 
> In addition, I found two more potential matter in this code.
> 
> The first one is lack of checks for permissions via attribute.
> When a child domain has an attribute which does not applied
> to the parent one, the child can have wider permissions that
> its parent.
> I think any attribute attached to child domain also have to
> be attached to the parent domain.
> (I guess it derived from legacy attribute implementation.)
>

Hierarchy.c:409, expand_avtab will expand all attribute usage into the
avtab. We don't care about attribute usage, only about net permissions
granted. 
 
> The later one is dependencies to the state of boolean.
> Hierarchy constraint allows a child domain to have
> permissions which are enabled for the parent, only if
> specific boolean is turned on. It potentially makes a
> situation that child domain has wider permissions.
> I think it is difficult to check in the policy toolchain, so
> checks on an avc entry creation is better way.
> 

We don't consider the state of booleans when doing analysis of the
policy. The idea was that the avtab is the maximum permissions allowed
and we always test on the maximum permissions. Whether a boolean may
reduce the parents permissions without doing so to the child I think is
a non-issue. Do you have an example of why this might be detrimental?


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

Mapping Linux GROUP to an SELinux user ?...

[Hasan Rezaul-CHR010]

Hi All,

Is there any way at all to map an entire Linux GROUP to an SELinux_user
??

For example if Linux User accounts (Admin1, Admin2, and Admin3), all
belong to the Linux group  "wadm".

Is there a simple or tricky way to map the entire Linux group    wadm ->
to staff_u ?

This way, any Linux user account that happens to be part of the "wadm"
group would automatically be mapped to staff_u  ? This way we don't have
to execute several semanage commands to create all those individual
mappings ?

Thanks as always.


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

Re: hierarchy_check_constraints() needs reworks?

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2008-07-24 at 14:38 +0900, KaiGai Kohei wrote:
>> I found out that hierarchy_check_constraints() in libsepol
>> does not work correctly, as follows:
>>
>> ---- example: foo.te ----
>> module foo 1.0;
>>
>> require {
>>         class file { read write getattr setattr ioctl };
>> };
>>
>> type src;
>> type src.child;
>> type tgt;
>>
>> allow src       tgt : file { read write };
>> allow src.child tgt : file { read write getattr setattr };
>> ----------
>> [root@fedora9 kaigai]# checkmodule -m -M foo.te -o foo.mod
>> checkmodule:  loading policy configuration from foo.te
>> checkmodule:  policy configuration loaded
>> checkmodule:  writing binary representation (version 8) to foo.mod
>> [root@fedora9 kaigai]# /usr/sbin/semodule -i foo.pp
> 
> Check /etc/selinux/semanage.conf to see if you have expand-check=1 set;
> otherwise, there is no hierarchy checking or neverallow checking
> occurring there.  Disabled by default in Fedora due to the overhead and
> the view that it should be handled at policy build time rather than
> insertion time.  refpolicy has a make validate target that runs
> semodule_link followed by semodule_expand manually.

Thanks for your information.

I could get an expected behavior under expand-check=1.

[root@fedora9 ~]# semodule -i ~kaigai/foo.pp
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types sbj.child and tgt : file {  getattr setattr }
libsepol.hierarchy_check_constraints: 1 total errors found during hierarchy check
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!
[root@fedora9 ~]#

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

Re: Mapping Linux GROUP to an SELinux user ?...

[Stephen Smalley]

On Thu, 2008-07-24 at 14:22 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> Is there any way at all to map an entire Linux GROUP to an SELinux_user
> ??
> 
> For example if Linux User accounts (Admin1, Admin2, and Admin3), all
> belong to the Linux group  "wadm".
> 
> Is there a simple or tricky way to map the entire Linux group    wadm ->
> to staff_u ?
> 
> This way, any Linux user account that happens to be part of the "wadm"
> group would automatically be mapped to staff_u  ? This way we don't have
> to execute several semanage commands to create all those individual
> mappings ?

Not presently, but one could certainly implement such support in the
userland (pam_selinux + libselinux getseuserbyname).



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

Re: hierarchy_check_constraints() needs reworks?

[KaiGai Kohei]

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> In addition, I found two more potential matter in this code.

Sorry, I also found both of them derived from my code misreading. :(


>> The first one is lack of checks for permissions via attribute.
>> When a child domain has an attribute which does not applied
>> to the parent one, the child can have wider permissions that
>> its parent.
>> I think any attribute attached to child domain also have to
>> be attached to the parent domain.
>> (I guess it derived from legacy attribute implementation.)
>>
> 
> Hierarchy.c:409, expand_avtab will expand all attribute usage into the
> avtab. We don't care about attribute usage, only about net permissions
> granted. 

I understood. The expand_avtab_node() callback indeed expand all
attributes before hierarchy checks.

BTW, is it really needed to expand attributes to check hierarchy
relationship?
I think that comparison for attribute ebitmaps can detect hierarchy
violation between parent and children. In other word, this constraint
can be rewritten as "as attribute of child type has to be attached to
the parent type".
It is also useful to detect privileged attribute like mcssetcats.

>> The later one is dependencies to the state of boolean.
>> Hierarchy constraint allows a child domain to have
>> permissions which are enabled for the parent, only if
>> specific boolean is turned on. It potentially makes a
>> situation that child domain has wider permissions.
>> I think it is difficult to check in the policy toolchain, so
>> checks on an avc entry creation is better way.
>>
> 
> We don't consider the state of booleans when doing analysis of the
> policy. The idea was that the avtab is the maximum permissions allowed
> and we always test on the maximum permissions. Whether a boolean may
> reduce the parents permissions without doing so to the child I think is
> a non-issue. Do you have an example of why this might be detrimental?

It was also my code misreading. Please forget it.

I seemed to me check_avtab_hierarchy_callback() compared unconditional
permissions and conditional one, but this callback is invoked with
NULL of opt_cond_list for unconditional one.

I confirmed the following policy makes hierarchy violation.
   type smbd_t.user;
   allow smbd_t.user user_home_t : file { getattr read };

[root@fedora9 ~]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted foo module
/usr/bin/checkmodule:  loading policy configuration from tmp/foo.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 8) to tmp/foo.mod
Creating targeted foo.pp policy package
rm tmp/foo.mod.fc tmp/foo.mod
[root@fedora9 ~]# semodule -i foo.pp
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types smbd_t.user and user_home_t : file {  read getattr }
libsepol.hierarchy_check_constraints: 1 total errors found during hierarchy check
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

Re: Mapping Linux GROUP to an SELinux user ?...

[Karl MacMillan]

On Thu, Jul 24, 2008 at 9:05 PM, Stephen Smalley
<stephen.smalley@gmail.com> wrote:
> On Thu, 2008-07-24 at 14:22 -0400, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> Is there any way at all to map an entire Linux GROUP to an SELinux_user
>> ??
>>
>> For example if Linux User accounts (Admin1, Admin2, and Admin3), all
>> belong to the Linux group  "wadm".
>>
>> Is there a simple or tricky way to map the entire Linux group    wadm ->
>> to staff_u ?
>>
>> This way, any Linux user account that happens to be part of the "wadm"
>> group would automatically be mapped to staff_u  ? This way we don't have
>> to execute several semanage commands to create all those individual
>> mappings ?
>
> Not presently, but one could certainly implement such support in the
> userland (pam_selinux + libselinux getseuserbyname).
>

I know that we and others have done this in the past, though our
implementation at least is not really a general solution but something
specific for one situation.

A general solution would need to resolve what the semantics of the
mapping would be including what to do when multiple groups match. Not
really a problem, just requires some thought.

Karl

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

Re: Mapping Linux GROUP to an SELinux user ?...

[Daniel J Walsh]

Karl MacMillan wrote:
> On Thu, Jul 24, 2008 at 9:05 PM, Stephen Smalley
> <stephen.smalley@gmail.com> wrote:
>> On Thu, 2008-07-24 at 14:22 -0400, Hasan Rezaul-CHR010 wrote:
>>> Hi All,
>>>
>>> Is there any way at all to map an entire Linux GROUP to an SELinux_user
>>> ??
>>>
>>> For example if Linux User accounts (Admin1, Admin2, and Admin3), all
>>> belong to the Linux group  "wadm".
>>>
>>> Is there a simple or tricky way to map the entire Linux group    wadm ->
>>> to staff_u ?
>>>
>>> This way, any Linux user account that happens to be part of the "wadm"
>>> group would automatically be mapped to staff_u  ? This way we don't have
>>> to execute several semanage commands to create all those individual
>>> mappings ?
>> Not presently, but one could certainly implement such support in the
>> userland (pam_selinux + libselinux getseuserbyname).
>>
> 
> I know that we and others have done this in the past, though our
> implementation at least is not really a general solution but something
> specific for one situation.
> 
> A general solution would need to resolve what the semantics of the
> mapping would be including what to do when multiple groups match. Not
> really a problem, just requires some thought.
> 
> Karl
> 
> --
> 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.
First get seusers out of libsemanage.

libsemanage can be used to verify the selinux user exists and the level.
 Then use the same syntax as sudo, I believe group name is preceded by
an @ sign.

@engineering


I will code up a patch for libselinux, but we need work to allow
semanage to add this syntax.

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