MLS dominance check behavior on el7

MLS dominance check behavior on el7

[Ted Toth]

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

We currently have code running on el6 that does a MLS dominance check by
calling security_compute_av_raw with the security object class
SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the
python code below. When I run this code on el6 s1 dominates s0 however when
I run the same code on el7 s1 does not dominate s0. On both systems the
file read dominance check works as expected. Can anyone help me understand
why the context contains check does not work the same on both systems?

Ted

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

import selinux

SECCLASS_CONTEXT = selinux.string_to_security_class("context")
CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
SECCLASS_FILE = selinux.string_to_security_class("file")
FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")

raw_con1 = "user_u:user_r:user_t:s1"
raw_con2 = "user_u:user_r:user_t:s0"

avd = selinux.av_decision()
selinux.avc_reset()
try:
    rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
    if rc < 0:
        print("selinux.security_compute_av_raw failed for %s %s" %
(raw_con1, raw_con2))
    if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS:
        print("%s dominates %s" % (raw_con1, raw_con2))
    else:
        print("%s does not dominate %s" % (raw_con1, raw_con2))
except OSError, ex:
    print "exception calling selinux.security_compute_av_raw", ex

avd = selinux.av_decision()
selinux.avc_reset()
try:
    rc = selinux.security_compute_av_raw(raw_con1, raw_con2, SECCLASS_FILE,
FILE__READ, avd)
    if rc < 0:
        print("selinux.security_compute_av_raw failed for %s %s" %
(raw_con1, raw_con2))
    if (avd.allowed & FILE__READ) == FILE__READ:
        print("%s dominates %s" % (raw_con1, raw_con2))
    else:
        print("%s does not dominate %s" % (raw_con1, raw_con2))

except OSError:
    print "exception calling selinux.security_compute_av_raw", ex

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/10/2018 01:13 PM, Ted Toth wrote:
> We currently have code running on el6 that does a MLS dominance check by 
> calling security_compute_av_raw with the security object class 
> SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the 
> python code below. When I run this code on el6 s1 dominates s0 however 
> when I run the same code on el7 s1 does not dominate s0. On both systems 
> the file read dominance check works as expected. Can anyone help me 
> understand why the context contains check does not work the same on both 
> systems?

That would depend entirely on how the constraint is written in the 
policy.  I assume this is with the -mls policy on both?  seinfo 
--constrain | grep -C1 context would show you the constraint in the 
kernel policy.

Looks like refpolicy defines it as:
mlsconstrain context contains
         (( h1 dom h2 ) and ( l1 domby l2));

The 2nd part of the constraint was introduced by:
commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
Author: Harry Ciao <qingtao.cao@windriver.com>
Date:   Tue Feb 15 10:16:32 2011 +0800

     l1 domby l2 for contains MLS constraint

     As identified by Stephan Smalley, the current MLS constraint for the
     contains permission of the context class should consider the current
     level of a user along with the clearance level so that mls_systemlow
     is no longer considered contained in mls_systemhigh.

     Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>

This was to prevent a user from logging in at a level below their 
authorized range, in the unusual scenario where the user's low level was 
not s0/systemlow.

> 
> Ted
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> import selinux
> 
> SECCLASS_CONTEXT = selinux.string_to_security_class("context")
> CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
> SECCLASS_FILE = selinux.string_to_security_class("file")
> FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
> 
> raw_con1 = "user_u:user_r:user_t:s1"
> raw_con2 = "user_u:user_r:user_t:s0"
> 
> avd = selinux.av_decision()
> selinux.avc_reset()
> try:
>      rc = selinux.security_compute_av_raw(raw_con1, raw_con2, 
> SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>      if rc < 0:
>          print("selinux.security_compute_av_raw failed for %s %s" % 
> (raw_con1, raw_con2))
>      if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS:
>          print("%s dominates %s" % (raw_con1, raw_con2))
>      else:
>          print("%s does not dominate %s" % (raw_con1, raw_con2))
> except OSError, ex:
>      print "exception calling selinux.security_compute_av_raw", ex
> 
> avd = selinux.av_decision()
> selinux.avc_reset()
> try:
>      rc = selinux.security_compute_av_raw(raw_con1, raw_con2, 
> SECCLASS_FILE, FILE__READ, avd)
>      if rc < 0:
>          print("selinux.security_compute_av_raw failed for %s %s" % 
> (raw_con1, raw_con2))
>      if (avd.allowed & FILE__READ) == FILE__READ:
>          print("%s dominates %s" % (raw_con1, raw_con2))
>      else:
>          print("%s does not dominate %s" % (raw_con1, raw_con2))
> 
> except OSError:
>      print "exception calling selinux.security_compute_av_raw", ex
> 
> 
> 
> _______________________________________________
> 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: MLS dominance check behavior on el7

[Ted Toth]

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

Understood, thanks.

On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 09/10/2018 01:13 PM, Ted Toth wrote:
> > We currently have code running on el6 that does a MLS dominance check by
> > calling security_compute_av_raw with the security object class
> > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the
> > python code below. When I run this code on el6 s1 dominates s0 however
> > when I run the same code on el7 s1 does not dominate s0. On both systems
> > the file read dominance check works as expected. Can anyone help me
> > understand why the context contains check does not work the same on both
> > systems?
>
> That would depend entirely on how the constraint is written in the
> policy.  I assume this is with the -mls policy on both?  seinfo
> --constrain | grep -C1 context would show you the constraint in the
> kernel policy.
>
> Looks like refpolicy defines it as:
> mlsconstrain context contains
>          (( h1 dom h2 ) and ( l1 domby l2));
>
> The 2nd part of the constraint was introduced by:
> commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
> Author: Harry Ciao <qingtao.cao@windriver.com>
> Date:   Tue Feb 15 10:16:32 2011 +0800
>
>      l1 domby l2 for contains MLS constraint
>
>      As identified by Stephan Smalley, the current MLS constraint for the
>      contains permission of the context class should consider the current
>      level of a user along with the clearance level so that mls_systemlow
>      is no longer considered contained in mls_systemhigh.
>
>      Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
>
> This was to prevent a user from logging in at a level below their
> authorized range, in the unusual scenario where the user's low level was
> not s0/systemlow.
>
> >
> > Ted
> >
> >
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >
> > import selinux
> >
> > SECCLASS_CONTEXT = selinux.string_to_security_class("context")
> > CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT,
> "contains")
> > SECCLASS_FILE = selinux.string_to_security_class("file")
> > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
> >
> > raw_con1 = "user_u:user_r:user_t:s1"
> > raw_con2 = "user_u:user_r:user_t:s0"
> >
> > avd = selinux.av_decision()
> > selinux.avc_reset()
> > try:
> >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
> >      if rc < 0:
> >          print("selinux.security_compute_av_raw failed for %s %s" %
> > (raw_con1, raw_con2))
> >      if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS:
> >          print("%s dominates %s" % (raw_con1, raw_con2))
> >      else:
> >          print("%s does not dominate %s" % (raw_con1, raw_con2))
> > except OSError, ex:
> >      print "exception calling selinux.security_compute_av_raw", ex
> >
> > avd = selinux.av_decision()
> > selinux.avc_reset()
> > try:
> >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> > SECCLASS_FILE, FILE__READ, avd)
> >      if rc < 0:
> >          print("selinux.security_compute_av_raw failed for %s %s" %
> > (raw_con1, raw_con2))
> >      if (avd.allowed & FILE__READ) == FILE__READ:
> >          print("%s dominates %s" % (raw_con1, raw_con2))
> >      else:
> >          print("%s does not dominate %s" % (raw_con1, raw_con2))
> >
> > except OSError:
> >      print "exception calling selinux.security_compute_av_raw", ex
> >
> >
> >
> > _______________________________________________
> > 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.
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5169 bytes --]

Re: MLS dominance check behavior on el7

[Ted Toth]

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

mcstrans mcscolor.c also uses the same logic I'd been using to check
dominance so this too will no longer function as expected on el7. Do you
any suggestions for doing a 'generic' (one not tied to a specific resource
class) dominance check in lieu of context contains?

Ted

On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com> wrote:

> Understood, thanks.
>
> On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
>
>> On 09/10/2018 01:13 PM, Ted Toth wrote:
>> > We currently have code running on el6 that does a MLS dominance check
>> by
>> > calling security_compute_av_raw with the security object class
>> > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in
>> the
>> > python code below. When I run this code on el6 s1 dominates s0 however
>> > when I run the same code on el7 s1 does not dominate s0. On both
>> systems
>> > the file read dominance check works as expected. Can anyone help me
>> > understand why the context contains check does not work the same on
>> both
>> > systems?
>>
>> That would depend entirely on how the constraint is written in the
>> policy.  I assume this is with the -mls policy on both?  seinfo
>> --constrain | grep -C1 context would show you the constraint in the
>> kernel policy.
>>
>> Looks like refpolicy defines it as:
>> mlsconstrain context contains
>>          (( h1 dom h2 ) and ( l1 domby l2));
>>
>> The 2nd part of the constraint was introduced by:
>> commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
>> Author: Harry Ciao <qingtao.cao@windriver.com>
>> Date:   Tue Feb 15 10:16:32 2011 +0800
>>
>>      l1 domby l2 for contains MLS constraint
>>
>>      As identified by Stephan Smalley, the current MLS constraint for the
>>      contains permission of the context class should consider the current
>>      level of a user along with the clearance level so that mls_systemlow
>>      is no longer considered contained in mls_systemhigh.
>>
>>      Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
>>
>> This was to prevent a user from logging in at a level below their
>> authorized range, in the unusual scenario where the user's low level was
>> not s0/systemlow.
>>
>> >
>> > Ted
>> >
>> >
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> >
>> > import selinux
>> >
>> > SECCLASS_CONTEXT = selinux.string_to_security_class("context")
>> > CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT,
>> "contains")
>> > SECCLASS_FILE = selinux.string_to_security_class("file")
>> > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
>> >
>> > raw_con1 = "user_u:user_r:user_t:s1"
>> > raw_con2 = "user_u:user_r:user_t:s0"
>> >
>> > avd = selinux.av_decision()
>> > selinux.avc_reset()
>> > try:
>> >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>> > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>> >      if rc < 0:
>> >          print("selinux.security_compute_av_raw failed for %s %s" %
>> > (raw_con1, raw_con2))
>> >      if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS:
>> >          print("%s dominates %s" % (raw_con1, raw_con2))
>> >      else:
>> >          print("%s does not dominate %s" % (raw_con1, raw_con2))
>> > except OSError, ex:
>> >      print "exception calling selinux.security_compute_av_raw", ex
>> >
>> > avd = selinux.av_decision()
>> > selinux.avc_reset()
>> > try:
>> >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>> > SECCLASS_FILE, FILE__READ, avd)
>> >      if rc < 0:
>> >          print("selinux.security_compute_av_raw failed for %s %s" %
>> > (raw_con1, raw_con2))
>> >      if (avd.allowed & FILE__READ) == FILE__READ:
>> >          print("%s dominates %s" % (raw_con1, raw_con2))
>> >      else:
>> >          print("%s does not dominate %s" % (raw_con1, raw_con2))
>> >
>> > except OSError:
>> >      print "exception calling selinux.security_compute_av_raw", ex
>> >
>> >
>> >
>> > _______________________________________________
>> > 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.
>> >
>>
>>

[-- Attachment #2: Type: text/html, Size: 5802 bytes --]

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/10/2018 06:30 PM, Ted Toth wrote:
> mcstrans mcscolor.c also uses the same logic I'd been using to check 
> dominance so this too will no longer function as expected on el7. Do you 
> any suggestions for doing a 'generic' (one not tied to a specific 
> resource class) dominance check in lieu of context contains?

You should probably define your own permission with its own constraint 
to avoid depending on the base policy's particular constraint 
definitions.  Certainly for your own code.  For mcstrans, mcscolor 
probably ought to be switched to using at least a separate permission in 
the context class if not its own class to avoid overloading the meaning 
with pam_selinux's usage (or vice versa, but likely harder to change 
pam_selinux at this point).

It is possible to define an entirely new class, its permissions, and its 
mls constraints via a CIL module IIUC, without needing to change the 
base policy.

I don't think you can add a permission to an existing class via a CIL 
module currently, unfortunately, so you can't just extend the context 
class without modifying the base policy.  So it may be easier to define 
an entirely new class.

The class and permission ought to be specific to the usage.  For 
example, mcstrans could have its own class (mcstrans) with its own 
permissions (e.g. color_match or color_use or ...) that abstract away 
the logical check being performed.  Dominance checks performed for 
different reasons ought to use different permissions so that one can 
distinguish what TE pairs are allowed them.

Your code could likewise define and use its own class and permission.

Does that make sense?

> 
> Ted
> 
> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com 
> <mailto:txtoth@gmail.com>> wrote:
> 
>     Understood, thanks.
> 
>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov
>     <mailto:sds@tycho.nsa.gov>> wrote:
> 
>         On 09/10/2018 01:13 PM, Ted Toth wrote:
>          > We currently have code running on el6 that does a MLS
>         dominance check by
>          > calling security_compute_av_raw with the security object class
>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can
>         see in the
>          > python code below. When I run this code on el6 s1 dominates
>         s0 however
>          > when I run the same code on el7 s1 does not dominate s0. On
>         both systems
>          > the file read dominance check works as expected. Can anyone
>         help me
>          > understand why the context contains check does not work the
>         same on both
>          > systems?
> 
>         That would depend entirely on how the constraint is written in the
>         policy.  I assume this is with the -mls policy on both?  seinfo
>         --constrain | grep -C1 context would show you the constraint in the
>         kernel policy.
> 
>         Looks like refpolicy defines it as:
>         mlsconstrain context contains
>                   (( h1 dom h2 ) and ( l1 domby l2));
> 
>         The 2nd part of the constraint was introduced by:
>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
>         Author: Harry Ciao <qingtao.cao@windriver.com
>         <mailto:qingtao.cao@windriver.com>>
>         Date:   Tue Feb 15 10:16:32 2011 +0800
> 
>               l1 domby l2 for contains MLS constraint
> 
>               As identified by Stephan Smalley, the current MLS
>         constraint for the
>               contains permission of the context class should consider
>         the current
>               level of a user along with the clearance level so that
>         mls_systemlow
>               is no longer considered contained in mls_systemhigh.
> 
>               Signed-off-by: Harry Ciao <qingtao.cao@windriver.com
>         <mailto:qingtao.cao@windriver.com>>
> 
>         This was to prevent a user from logging in at a level below their
>         authorized range, in the unusual scenario where the user's low
>         level was
>         not s0/systemlow.
> 
>          >
>          > Ted
>          >
>          >
>         ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>          >
>          > import selinux
>          >
>          > SECCLASS_CONTEXT = selinux.string_to_security_class("context")
>          > CONTEXT__CONTAINS =
>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
>          > SECCLASS_FILE = selinux.string_to_security_class("file")
>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
>          >
>          > raw_con1 = "user_u:user_r:user_t:s1"
>          > raw_con2 = "user_u:user_r:user_t:s0"
>          >
>          > avd = selinux.av_decision()
>          > selinux.avc_reset()
>          > try:
>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>          >      if rc < 0:
>          >          print("selinux.security_compute_av_raw failed for %s
>         %s" %
>          > (raw_con1, raw_con2))
>          >      if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS:
>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>          >      else:
>          >          print("%s does not dominate %s" % (raw_con1, raw_con2))
>          > except OSError, ex:
>          >      print "exception calling
>         selinux.security_compute_av_raw", ex
>          >
>          > avd = selinux.av_decision()
>          > selinux.avc_reset()
>          > try:
>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>          > SECCLASS_FILE, FILE__READ, avd)
>          >      if rc < 0:
>          >          print("selinux.security_compute_av_raw failed for %s
>         %s" %
>          > (raw_con1, raw_con2))
>          >      if (avd.allowed & FILE__READ) == FILE__READ:
>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>          >      else:
>          >          print("%s does not dominate %s" % (raw_con1, raw_con2))
>          >
>          > except OSError:
>          >      print "exception calling
>         selinux.security_compute_av_raw", ex
>          >
>          >
>          >
>          > _______________________________________________
>          > Selinux mailing list
>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
>          > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov
>         <mailto:Selinux-leave@tycho.nsa.gov>.
>          > To get help, send an email containing "help" to
>         Selinux-request@tycho.nsa.gov
>         <mailto:Selinux-request@tycho.nsa.gov>.
>          >
> 

Re: MLS dominance check behavior on el7

[Joshua Brindle]

On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>
>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>> dominance so this too will no longer function as expected on el7. Do you any
>> suggestions for doing a 'generic' (one not tied to a specific resource
>> class) dominance check in lieu of context contains?
>
>
> You should probably define your own permission with its own constraint to
> avoid depending on the base policy's particular constraint definitions.
> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
> switched to using at least a separate permission in the context class if not
> its own class to avoid overloading the meaning with pam_selinux's usage (or
> vice versa, but likely harder to change pam_selinux at this point).
>

Isn't the actual question what the GLB of the 2 contexts is, rather
than what permissions one has on the other? It seems like a hack to
use permissions to figure out dominance.

Would a libselinux interface to determine glb and lub of 2 contexts
make sense? Or maybe add a default_range glb and lub option and then
calculate it using relabel?

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 12:53 PM, Joshua Brindle wrote:
> On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>
>>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>>> dominance so this too will no longer function as expected on el7. Do you any
>>> suggestions for doing a 'generic' (one not tied to a specific resource
>>> class) dominance check in lieu of context contains?
>>
>>
>> You should probably define your own permission with its own constraint to
>> avoid depending on the base policy's particular constraint definitions.
>> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
>> switched to using at least a separate permission in the context class if not
>> its own class to avoid overloading the meaning with pam_selinux's usage (or
>> vice versa, but likely harder to change pam_selinux at this point).
>>
> 
> Isn't the actual question what the GLB of the 2 contexts is, rather
> than what permissions one has on the other? It seems like a hack to
> use permissions to figure out dominance.
> 
> Would a libselinux interface to determine glb and lub of 2 contexts
> make sense? Or maybe add a default_range glb and lub option and then
> calculate it using relabel?

At least as used in mcstrans, it appears to be a way of matching which 
entry from the colors configuration to use.  So it is just a "Can 
context C1 use the colors specified for context C2?" question.  It just 
happens that the way they are deciding that for the MLS part is through 
the dominance relation.  And determining whether context C1 dominates 
context C2 is something only the kernel security server or libsepol with 
the same policy file loaded into it can answer, not libselinux or 
anything else.

Re: MLS dominance check behavior on el7

[Joshua Brindle]

On Tue, Sep 11, 2018 at 1:33 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/11/2018 12:53 PM, Joshua Brindle wrote:
>>
>> On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>>>
>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>
>>>>
>>>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>>>> dominance so this too will no longer function as expected on el7. Do you
>>>> any
>>>> suggestions for doing a 'generic' (one not tied to a specific resource
>>>> class) dominance check in lieu of context contains?
>>>
>>>
>>>
>>> You should probably define your own permission with its own constraint to
>>> avoid depending on the base policy's particular constraint definitions.
>>> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
>>> switched to using at least a separate permission in the context class if
>>> not
>>> its own class to avoid overloading the meaning with pam_selinux's usage
>>> (or
>>> vice versa, but likely harder to change pam_selinux at this point).
>>>
>>
>> Isn't the actual question what the GLB of the 2 contexts is, rather
>> than what permissions one has on the other? It seems like a hack to
>> use permissions to figure out dominance.
>>
>> Would a libselinux interface to determine glb and lub of 2 contexts
>> make sense? Or maybe add a default_range glb and lub option and then
>> calculate it using relabel?
>
>
> At least as used in mcstrans, it appears to be a way of matching which entry
> from the colors configuration to use.  So it is just a "Can context C1 use
> the colors specified for context C2?" question.  It just happens that the
> way they are deciding that for the MLS part is through the dominance
> relation.  And determining whether context C1 dominates context C2 is
> something only the kernel security server or libsepol with the same policy
> file loaded into it can answer, not libselinux or anything else.
>

I meant an libselinux as in a library interface to some file in
selinuxfs to calculate the glb.

If it is 'permission to see a color' that makes sense, I was thinking
the source context and target context have a glb that maps to the
color to be shown.

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 01:39 PM, Joshua Brindle wrote:
> On Tue, Sep 11, 2018 at 1:33 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/11/2018 12:53 PM, Joshua Brindle wrote:
>>>
>>> On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley <sds@tycho.nsa.gov>
>>> wrote:
>>>>
>>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>>
>>>>>
>>>>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>>>>> dominance so this too will no longer function as expected on el7. Do you
>>>>> any
>>>>> suggestions for doing a 'generic' (one not tied to a specific resource
>>>>> class) dominance check in lieu of context contains?
>>>>
>>>>
>>>>
>>>> You should probably define your own permission with its own constraint to
>>>> avoid depending on the base policy's particular constraint definitions.
>>>> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
>>>> switched to using at least a separate permission in the context class if
>>>> not
>>>> its own class to avoid overloading the meaning with pam_selinux's usage
>>>> (or
>>>> vice versa, but likely harder to change pam_selinux at this point).
>>>>
>>>
>>> Isn't the actual question what the GLB of the 2 contexts is, rather
>>> than what permissions one has on the other? It seems like a hack to
>>> use permissions to figure out dominance.
>>>
>>> Would a libselinux interface to determine glb and lub of 2 contexts
>>> make sense? Or maybe add a default_range glb and lub option and then
>>> calculate it using relabel?
>>
>>
>> At least as used in mcstrans, it appears to be a way of matching which entry
>> from the colors configuration to use.  So it is just a "Can context C1 use
>> the colors specified for context C2?" question.  It just happens that the
>> way they are deciding that for the MLS part is through the dominance
>> relation.  And determining whether context C1 dominates context C2 is
>> something only the kernel security server or libsepol with the same policy
>> file loaded into it can answer, not libselinux or anything else.
>>
> 
> I meant an libselinux as in a library interface to some file in
> selinuxfs to calculate the glb.
> 
> If it is 'permission to see a color' that makes sense, I was thinking
> the source context and target context have a glb that maps to the
> color to be shown.

That doesn't seem to match the existing mcstrans logic or colors 
configuration file.  So, sure he could rewrite mcstrans and its 
configuration format, add a new libselinux interface, add a new kernel 
interface, and implement a new kernel security server function, but he 
just wanted to make something that was already working on rhel6 to work 
on rhel7, and which only broke because a constraint changed out 
underneath to address a concern with pam_selinux/login.  Easiest 
approach is to define a new class/perm and define the old constraint for 
it.  Requires adding a CIL module for the policy piece and then a couple 
of lines changed in mcstrans and his own code and he is done.

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 10:41 AM, Stephen Smalley wrote:
> On 09/10/2018 06:30 PM, Ted Toth wrote:
>> mcstrans mcscolor.c also uses the same logic I'd been using to check 
>> dominance so this too will no longer function as expected on el7. Do 
>> you any suggestions for doing a 'generic' (one not tied to a specific 
>> resource class) dominance check in lieu of context contains?
> 
> You should probably define your own permission with its own constraint 
> to avoid depending on the base policy's particular constraint 
> definitions.  Certainly for your own code.  For mcstrans, mcscolor 
> probably ought to be switched to using at least a separate permission in 
> the context class if not its own class to avoid overloading the meaning 
> with pam_selinux's usage (or vice versa, but likely harder to change 
> pam_selinux at this point).
> 
> It is possible to define an entirely new class, its permissions, and its 
> mls constraints via a CIL module IIUC, without needing to change the 
> base policy.
> 
> I don't think you can add a permission to an existing class via a CIL 
> module currently, unfortunately, so you can't just extend the context 
> class without modifying the base policy.  So it may be easier to define 
> an entirely new class.
> 
> The class and permission ought to be specific to the usage.  For 
> example, mcstrans could have its own class (mcstrans) with its own 
> permissions (e.g. color_match or color_use or ...) that abstract away 
> the logical check being performed.  Dominance checks performed for 
> different reasons ought to use different permissions so that one can 
> distinguish what TE pairs are allowed them.
> 
> Your code could likewise define and use its own class and permission.
> 
> Does that make sense?

BTW, I noticed there is another permission ("translate") defined in the 
context class and its constraint is ((h1 dom h2) or (t1 == 
mlstranslate)).  I would have guessed that it was intended as a 
front-end service check over what processes could request context 
translations from mcstrans or what contexts they could translate, but I 
don't see it being used in mcstrans anywhere.  Is this a legacy thing 
from early setransd/mcstransd days?  There is a TODO comment in mcstrans 
process_request() that suggests there was an intent to perform a 
dominance check between the requester context and the specified context, 
but that's not implemented.  Appears to be allowed in current policy for 
all domains to the setrans_t domain itself.

> 
>>
>> Ted
>>
>> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com 
>> <mailto:txtoth@gmail.com>> wrote:
>>
>>     Understood, thanks.
>>
>>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov
>>     <mailto:sds@tycho.nsa.gov>> wrote:
>>
>>         On 09/10/2018 01:13 PM, Ted Toth wrote:
>>          > We currently have code running on el6 that does a MLS
>>         dominance check by
>>          > calling security_compute_av_raw with the security object class
>>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can
>>         see in the
>>          > python code below. When I run this code on el6 s1 dominates
>>         s0 however
>>          > when I run the same code on el7 s1 does not dominate s0. On
>>         both systems
>>          > the file read dominance check works as expected. Can anyone
>>         help me
>>          > understand why the context contains check does not work the
>>         same on both
>>          > systems?
>>
>>         That would depend entirely on how the constraint is written in 
>> the
>>         policy.  I assume this is with the -mls policy on both?  seinfo
>>         --constrain | grep -C1 context would show you the constraint 
>> in the
>>         kernel policy.
>>
>>         Looks like refpolicy defines it as:
>>         mlsconstrain context contains
>>                   (( h1 dom h2 ) and ( l1 domby l2));
>>
>>         The 2nd part of the constraint was introduced by:
>>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
>>         Author: Harry Ciao <qingtao.cao@windriver.com
>>         <mailto:qingtao.cao@windriver.com>>
>>         Date:   Tue Feb 15 10:16:32 2011 +0800
>>
>>               l1 domby l2 for contains MLS constraint
>>
>>               As identified by Stephan Smalley, the current MLS
>>         constraint for the
>>               contains permission of the context class should consider
>>         the current
>>               level of a user along with the clearance level so that
>>         mls_systemlow
>>               is no longer considered contained in mls_systemhigh.
>>
>>               Signed-off-by: Harry Ciao <qingtao.cao@windriver.com
>>         <mailto:qingtao.cao@windriver.com>>
>>
>>         This was to prevent a user from logging in at a level below their
>>         authorized range, in the unusual scenario where the user's low
>>         level was
>>         not s0/systemlow.
>>
>>          >
>>          > Ted
>>          >
>>          >
>>         
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
>>          >
>>          > import selinux
>>          >
>>          > SECCLASS_CONTEXT = selinux.string_to_security_class("context")
>>          > CONTEXT__CONTAINS =
>>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
>>          > SECCLASS_FILE = selinux.string_to_security_class("file")
>>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
>>          >
>>          > raw_con1 = "user_u:user_r:user_t:s1"
>>          > raw_con2 = "user_u:user_r:user_t:s0"
>>          >
>>          > avd = selinux.av_decision()
>>          > selinux.avc_reset()
>>          > try:
>>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>>          >      if rc < 0:
>>          >          print("selinux.security_compute_av_raw failed for %s
>>         %s" %
>>          > (raw_con1, raw_con2))
>>          >      if (avd.allowed & CONTEXT__CONTAINS) == 
>> CONTEXT__CONTAINS:
>>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>>          >      else:
>>          >          print("%s does not dominate %s" % (raw_con1, 
>> raw_con2))
>>          > except OSError, ex:
>>          >      print "exception calling
>>         selinux.security_compute_av_raw", ex
>>          >
>>          > avd = selinux.av_decision()
>>          > selinux.avc_reset()
>>          > try:
>>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
>>          > SECCLASS_FILE, FILE__READ, avd)
>>          >      if rc < 0:
>>          >          print("selinux.security_compute_av_raw failed for %s
>>         %s" %
>>          > (raw_con1, raw_con2))
>>          >      if (avd.allowed & FILE__READ) == FILE__READ:
>>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>>          >      else:
>>          >          print("%s does not dominate %s" % (raw_con1, 
>> raw_con2))
>>          >
>>          > except OSError:
>>          >      print "exception calling
>>         selinux.security_compute_av_raw", ex
>>          >
>>          >
>>          >
>>          > _______________________________________________
>>          > Selinux mailing list
>>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
>>          > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov
>>         <mailto:Selinux-leave@tycho.nsa.gov>.
>>          > To get help, send an email containing "help" to
>>         Selinux-request@tycho.nsa.gov
>>         <mailto:Selinux-request@tycho.nsa.gov>.
>>          >
>>
> 

Re: MLS dominance check behavior on el7

[Ted Toth]

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

Yes I too noticed the translate permission but couldn't find any info
related to it intended purpose. Regarding CIL unfortunately I have zero
experience with it but I've installed the compiler and started reading
through https://github.com/SELinuxProject/cil/wiki (any other pointers to
useful info would be appreciated). I have written lots of policy would it
be possible to add a class/permissions/mlsconstraints in an old-fashion
policy module?

On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
> > On 09/10/2018 06:30 PM, Ted Toth wrote:
> >> mcstrans mcscolor.c also uses the same logic I'd been using to check
> >> dominance so this too will no longer function as expected on el7. Do
> >> you any suggestions for doing a 'generic' (one not tied to a specific
> >> resource class) dominance check in lieu of context contains?
> >
> > You should probably define your own permission with its own constraint
> > to avoid depending on the base policy's particular constraint
> > definitions.  Certainly for your own code.  For mcstrans, mcscolor
> > probably ought to be switched to using at least a separate permission in
> > the context class if not its own class to avoid overloading the meaning
> > with pam_selinux's usage (or vice versa, but likely harder to change
> > pam_selinux at this point).
> >
> > It is possible to define an entirely new class, its permissions, and its
> > mls constraints via a CIL module IIUC, without needing to change the
> > base policy.
> >
> > I don't think you can add a permission to an existing class via a CIL
> > module currently, unfortunately, so you can't just extend the context
> > class without modifying the base policy.  So it may be easier to define
> > an entirely new class.
> >
> > The class and permission ought to be specific to the usage.  For
> > example, mcstrans could have its own class (mcstrans) with its own
> > permissions (e.g. color_match or color_use or ...) that abstract away
> > the logical check being performed.  Dominance checks performed for
> > different reasons ought to use different permissions so that one can
> > distinguish what TE pairs are allowed them.
> >
> > Your code could likewise define and use its own class and permission.
> >
> > Does that make sense?
>
> BTW, I noticed there is another permission ("translate") defined in the
> context class and its constraint is ((h1 dom h2) or (t1 ==
> mlstranslate)).  I would have guessed that it was intended as a
> front-end service check over what processes could request context
> translations from mcstrans or what contexts they could translate, but I
> don't see it being used in mcstrans anywhere.  Is this a legacy thing
> from early setransd/mcstransd days?  There is a TODO comment in mcstrans
> process_request() that suggests there was an intent to perform a
> dominance check between the requester context and the specified context,
> but that's not implemented.  Appears to be allowed in current policy for
> all domains to the setrans_t domain itself.
>
> >
> >>
> >> Ted
> >>
> >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com
> >> <mailto:txtoth@gmail.com>> wrote:
> >>
> >>     Understood, thanks.
> >>
> >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov
> >>     <mailto:sds@tycho.nsa.gov>> wrote:
> >>
> >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
> >>          > We currently have code running on el6 that does a MLS
> >>         dominance check by
> >>          > calling security_compute_av_raw with the security object
> class
> >>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can
> >>         see in the
> >>          > python code below. When I run this code on el6 s1 dominates
> >>         s0 however
> >>          > when I run the same code on el7 s1 does not dominate s0. On
> >>         both systems
> >>          > the file read dominance check works as expected. Can anyone
> >>         help me
> >>          > understand why the context contains check does not work the
> >>         same on both
> >>          > systems?
> >>
> >>         That would depend entirely on how the constraint is written in
> >> the
> >>         policy.  I assume this is with the -mls policy on both?  seinfo
> >>         --constrain | grep -C1 context would show you the constraint
> >> in the
> >>         kernel policy.
> >>
> >>         Looks like refpolicy defines it as:
> >>         mlsconstrain context contains
> >>                   (( h1 dom h2 ) and ( l1 domby l2));
> >>
> >>         The 2nd part of the constraint was introduced by:
> >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
> >>         Author: Harry Ciao <qingtao.cao@windriver.com
> >>         <mailto:qingtao.cao@windriver.com>>
> >>         Date:   Tue Feb 15 10:16:32 2011 +0800
> >>
> >>               l1 domby l2 for contains MLS constraint
> >>
> >>               As identified by Stephan Smalley, the current MLS
> >>         constraint for the
> >>               contains permission of the context class should consider
> >>         the current
> >>               level of a user along with the clearance level so that
> >>         mls_systemlow
> >>               is no longer considered contained in mls_systemhigh.
> >>
> >>               Signed-off-by: Harry Ciao <qingtao.cao@windriver.com
> >>         <mailto:qingtao.cao@windriver.com>>
> >>
> >>         This was to prevent a user from logging in at a level below
> their
> >>         authorized range, in the unusual scenario where the user's low
> >>         level was
> >>         not s0/systemlow.
> >>
> >>          >
> >>          > Ted
> >>          >
> >>          >
> >>
> >>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> >>
> >>          >
> >>          > import selinux
> >>          >
> >>          > SECCLASS_CONTEXT =
> selinux.string_to_security_class("context")
> >>          > CONTEXT__CONTAINS =
> >>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
> >>          > SECCLASS_FILE = selinux.string_to_security_class("file")
> >>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
> >>          >
> >>          > raw_con1 = "user_u:user_r:user_t:s1"
> >>          > raw_con2 = "user_u:user_r:user_t:s0"
> >>          >
> >>          > avd = selinux.av_decision()
> >>          > selinux.avc_reset()
> >>          > try:
> >>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
> >>          >      if rc < 0:
> >>          >          print("selinux.security_compute_av_raw failed for %s
> >>         %s" %
> >>          > (raw_con1, raw_con2))
> >>          >      if (avd.allowed & CONTEXT__CONTAINS) ==
> >> CONTEXT__CONTAINS:
> >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
> >>          >      else:
> >>          >          print("%s does not dominate %s" % (raw_con1,
> >> raw_con2))
> >>          > except OSError, ex:
> >>          >      print "exception calling
> >>         selinux.security_compute_av_raw", ex
> >>          >
> >>          > avd = selinux.av_decision()
> >>          > selinux.avc_reset()
> >>          > try:
> >>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> >>          > SECCLASS_FILE, FILE__READ, avd)
> >>          >      if rc < 0:
> >>          >          print("selinux.security_compute_av_raw failed for %s
> >>         %s" %
> >>          > (raw_con1, raw_con2))
> >>          >      if (avd.allowed & FILE__READ) == FILE__READ:
> >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
> >>          >      else:
> >>          >          print("%s does not dominate %s" % (raw_con1,
> >> raw_con2))
> >>          >
> >>          > except OSError:
> >>          >      print "exception calling
> >>         selinux.security_compute_av_raw", ex
> >>          >
> >>          >
> >>          >
> >>          > _______________________________________________
> >>          > Selinux mailing list
> >>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
> >>          > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov
> >>         <mailto:Selinux-leave@tycho.nsa.gov>.
> >>          > To get help, send an email containing "help" to
> >>         Selinux-request@tycho.nsa.gov
> >>         <mailto:Selinux-request@tycho.nsa.gov>.
> >>          >
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 12659 bytes --]

Re: MLS dominance check behavior on el7

[Yuli Khodorkovskiy]

The selinux repo has more up to date and digestible documentation: https://github.com/SELinuxProject/selinux/tree/master/secilc/docs

> On Sep 11, 2018, at 2:49 PM, Ted Toth <txtoth@gmail.com> wrote:
> 
> Yes I too noticed the translate permission but couldn't find any info related to it intended purpose. Regarding CIL unfortunately I have zero experience with it but I've installed the compiler and started reading through https://github.com/SELinuxProject/cil/wiki (any other pointers to useful info would be appreciated). I have written lots of policy would it be possible to add a class/permissions/mlsconstraints in an old-fashion policy module?
> 
> On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
> > On 09/10/2018 06:30 PM, Ted Toth wrote:
> >> mcstrans mcscolor.c also uses the same logic I'd been using to check 
> >> dominance so this too will no longer function as expected on el7. Do 
> >> you any suggestions for doing a 'generic' (one not tied to a specific 
> >> resource class) dominance check in lieu of context contains?
> > 
> > You should probably define your own permission with its own constraint 
> > to avoid depending on the base policy's particular constraint 
> > definitions.  Certainly for your own code.  For mcstrans, mcscolor 
> > probably ought to be switched to using at least a separate permission in 
> > the context class if not its own class to avoid overloading the meaning 
> > with pam_selinux's usage (or vice versa, but likely harder to change 
> > pam_selinux at this point).
> > 
> > It is possible to define an entirely new class, its permissions, and its 
> > mls constraints via a CIL module IIUC, without needing to change the 
> > base policy.
> > 
> > I don't think you can add a permission to an existing class via a CIL 
> > module currently, unfortunately, so you can't just extend the context 
> > class without modifying the base policy.  So it may be easier to define 
> > an entirely new class.
> > 
> > The class and permission ought to be specific to the usage.  For 
> > example, mcstrans could have its own class (mcstrans) with its own 
> > permissions (e.g. color_match or color_use or ...) that abstract away 
> > the logical check being performed.  Dominance checks performed for 
> > different reasons ought to use different permissions so that one can 
> > distinguish what TE pairs are allowed them.
> > 
> > Your code could likewise define and use its own class and permission.
> > 
> > Does that make sense?
> 
> BTW, I noticed there is another permission ("translate") defined in the 
> context class and its constraint is ((h1 dom h2) or (t1 == 
> mlstranslate)).  I would have guessed that it was intended as a 
> front-end service check over what processes could request context 
> translations from mcstrans or what contexts they could translate, but I 
> don't see it being used in mcstrans anywhere.  Is this a legacy thing 
> from early setransd/mcstransd days?  There is a TODO comment in mcstrans 
> process_request() that suggests there was an intent to perform a 
> dominance check between the requester context and the specified context, 
> but that's not implemented.  Appears to be allowed in current policy for 
> all domains to the setrans_t domain itself.
> 
> > 
> >>
> >> Ted
> >>
> >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com 
> >> <mailto:txtoth@gmail.com>> wrote:
> >>
> >>     Understood, thanks.
> >>
> >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley <sds@tycho.nsa.gov
> >>     <mailto:sds@tycho.nsa.gov>> wrote:
> >>
> >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
> >>          > We currently have code running on el6 that does a MLS
> >>         dominance check by
> >>          > calling security_compute_av_raw with the security object class
> >>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can
> >>         see in the
> >>          > python code below. When I run this code on el6 s1 dominates
> >>         s0 however
> >>          > when I run the same code on el7 s1 does not dominate s0. On
> >>         both systems
> >>          > the file read dominance check works as expected. Can anyone
> >>         help me
> >>          > understand why the context contains check does not work the
> >>         same on both
> >>          > systems?
> >>
> >>         That would depend entirely on how the constraint is written in 
> >> the
> >>         policy.  I assume this is with the -mls policy on both?  seinfo
> >>         --constrain | grep -C1 context would show you the constraint 
> >> in the
> >>         kernel policy.
> >>
> >>         Looks like refpolicy defines it as:
> >>         mlsconstrain context contains
> >>                   (( h1 dom h2 ) and ( l1 domby l2));
> >>
> >>         The 2nd part of the constraint was introduced by:
> >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
> >>         Author: Harry Ciao <qingtao.cao@windriver.com
> >>         <mailto:qingtao.cao@windriver.com>>
> >>         Date:   Tue Feb 15 10:16:32 2011 +0800
> >>
> >>               l1 domby l2 for contains MLS constraint
> >>
> >>               As identified by Stephan Smalley, the current MLS
> >>         constraint for the
> >>               contains permission of the context class should consider
> >>         the current
> >>               level of a user along with the clearance level so that
> >>         mls_systemlow
> >>               is no longer considered contained in mls_systemhigh.
> >>
> >>               Signed-off-by: Harry Ciao <qingtao.cao@windriver.com
> >>         <mailto:qingtao.cao@windriver.com>>
> >>
> >>         This was to prevent a user from logging in at a level below their
> >>         authorized range, in the unusual scenario where the user's low
> >>         level was
> >>         not s0/systemlow.
> >>
> >>          >
> >>          > Ted
> >>          >
> >>          >
> >>         
> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
> >>
> >>          >
> >>          > import selinux
> >>          >
> >>          > SECCLASS_CONTEXT = selinux.string_to_security_class("context")
> >>          > CONTEXT__CONTAINS =
> >>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
> >>          > SECCLASS_FILE = selinux.string_to_security_class("file")
> >>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read")
> >>          >
> >>          > raw_con1 = "user_u:user_r:user_t:s1"
> >>          > raw_con2 = "user_u:user_r:user_t:s0"
> >>          >
> >>          > avd = selinux.av_decision()
> >>          > selinux.avc_reset()
> >>          > try:
> >>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
> >>          >      if rc < 0:
> >>          >          print("selinux.security_compute_av_raw failed for %s
> >>         %s" %
> >>          > (raw_con1, raw_con2))
> >>          >      if (avd.allowed & CONTEXT__CONTAINS) == 
> >> CONTEXT__CONTAINS:
> >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
> >>          >      else:
> >>          >          print("%s does not dominate %s" % (raw_con1, 
> >> raw_con2))
> >>          > except OSError, ex:
> >>          >      print "exception calling
> >>         selinux.security_compute_av_raw", ex
> >>          >
> >>          > avd = selinux.av_decision()
> >>          > selinux.avc_reset()
> >>          > try:
> >>          >      rc = selinux.security_compute_av_raw(raw_con1, raw_con2,
> >>          > SECCLASS_FILE, FILE__READ, avd)
> >>          >      if rc < 0:
> >>          >          print("selinux.security_compute_av_raw failed for %s
> >>         %s" %
> >>          > (raw_con1, raw_con2))
> >>          >      if (avd.allowed & FILE__READ) == FILE__READ:
> >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
> >>          >      else:
> >>          >          print("%s does not dominate %s" % (raw_con1, 
> >> raw_con2))
> >>          >
> >>          > except OSError:
> >>          >      print "exception calling
> >>         selinux.security_compute_av_raw", ex
> >>          >
> >>          >
> >>          >
> >>          > _______________________________________________
> >>          > Selinux mailing list
> >>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
> >>          > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov
> >>         <mailto:Selinux-leave@tycho.nsa.gov>.
> >>          > To get help, send an email containing "help" to
> >>         Selinux-request@tycho.nsa.gov
> >>         <mailto: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: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 02:49 PM, Ted Toth wrote:
> Yes I too noticed the translate permission but couldn't find any info 
> related to it intended purpose. Regarding CIL unfortunately I have zero 
> experience with it but I've installed the compiler and started reading 
> through https://github.com/SELinuxProject/cil/wiki (any other pointers 
> to useful info would be appreciated). I have written lots of policy 
> would it be possible to add a class/permissions/mlsconstraints in an 
> old-fashion policy module?

The older binary modules didn't support those kinds of statements 
outside of the base module.  Try this:
$ cat > mcstrans.cil <<EOF
; define a mcstrans class with one permission color_use
(class mcstrans (color_use))
; allow all domains mcstrans color_use permission to themselves
(allow domain self (mcstrans (color_use)))
; only allow mcstrans color_use permission when h1 dominates h2
(mlsconstrain (mcstrans (color_use)) (dom h1 h2))
; append the new mcstrans class to the end after all others
(classorder (unordered mcstrans))
EOF

$ sudo semodule -i mcstrans.cil

Then try performing permission checks with "mcstrans" as your class and 
"color_use" as your permission, between a domain and itself, with 
different levels.

> 
> On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley <sds@tycho.nsa.gov 
> <mailto:sds@tycho.nsa.gov>> wrote:
> 
>     On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>      > On 09/10/2018 06:30 PM, Ted Toth wrote:
>      >> mcstrans mcscolor.c also uses the same logic I'd been using to
>     check
>      >> dominance so this too will no longer function as expected on
>     el7. Do
>      >> you any suggestions for doing a 'generic' (one not tied to a
>     specific
>      >> resource class) dominance check in lieu of context contains?
>      >
>      > You should probably define your own permission with its own
>     constraint
>      > to avoid depending on the base policy's particular constraint
>      > definitions.  Certainly for your own code.  For mcstrans, mcscolor
>      > probably ought to be switched to using at least a separate
>     permission in
>      > the context class if not its own class to avoid overloading the
>     meaning
>      > with pam_selinux's usage (or vice versa, but likely harder to change
>      > pam_selinux at this point).
>      >
>      > It is possible to define an entirely new class, its permissions,
>     and its
>      > mls constraints via a CIL module IIUC, without needing to change the
>      > base policy.
>      >
>      > I don't think you can add a permission to an existing class via a
>     CIL
>      > module currently, unfortunately, so you can't just extend the
>     context
>      > class without modifying the base policy.  So it may be easier to
>     define
>      > an entirely new class.
>      >
>      > The class and permission ought to be specific to the usage.  For
>      > example, mcstrans could have its own class (mcstrans) with its own
>      > permissions (e.g. color_match or color_use or ...) that abstract
>     away
>      > the logical check being performed.  Dominance checks performed for
>      > different reasons ought to use different permissions so that one can
>      > distinguish what TE pairs are allowed them.
>      >
>      > Your code could likewise define and use its own class and permission.
>      >
>      > Does that make sense?
> 
>     BTW, I noticed there is another permission ("translate") defined in the
>     context class and its constraint is ((h1 dom h2) or (t1 ==
>     mlstranslate)).  I would have guessed that it was intended as a
>     front-end service check over what processes could request context
>     translations from mcstrans or what contexts they could translate, but I
>     don't see it being used in mcstrans anywhere.  Is this a legacy thing
>     from early setransd/mcstransd days?  There is a TODO comment in
>     mcstrans
>     process_request() that suggests there was an intent to perform a
>     dominance check between the requester context and the specified
>     context,
>     but that's not implemented.  Appears to be allowed in current policy
>     for
>     all domains to the setrans_t domain itself.
> 
>      >
>      >>
>      >> Ted
>      >>
>      >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com
>     <mailto:txtoth@gmail.com>
>      >> <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>> wrote:
>      >>
>      >>     Understood, thanks.
>      >>
>      >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
>     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
>      >>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>> wrote:
>      >>
>      >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
>      >>          > We currently have code running on el6 that does a MLS
>      >>         dominance check by
>      >>          > calling security_compute_av_raw with the security
>     object class
>      >>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as
>     you can
>      >>         see in the
>      >>          > python code below. When I run this code on el6 s1
>     dominates
>      >>         s0 however
>      >>          > when I run the same code on el7 s1 does not dominate
>     s0. On
>      >>         both systems
>      >>          > the file read dominance check works as expected. Can
>     anyone
>      >>         help me
>      >>          > understand why the context contains check does not
>     work the
>      >>         same on both
>      >>          > systems?
>      >>
>      >>         That would depend entirely on how the constraint is
>     written in
>      >> the
>      >>         policy.  I assume this is with the -mls policy on both? 
>     seinfo
>      >>         --constrain | grep -C1 context would show you the
>     constraint
>      >> in the
>      >>         kernel policy.
>      >>
>      >>         Looks like refpolicy defines it as:
>      >>         mlsconstrain context contains
>      >>                   (( h1 dom h2 ) and ( l1 domby l2));
>      >>
>      >>         The 2nd part of the constraint was introduced by:
>      >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
>      >>         Author: Harry Ciao <qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>
>      >>         <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>>>
>      >>         Date:   Tue Feb 15 10:16:32 2011 +0800
>      >>
>      >>               l1 domby l2 for contains MLS constraint
>      >>
>      >>               As identified by Stephan Smalley, the current MLS
>      >>         constraint for the
>      >>               contains permission of the context class should
>     consider
>      >>         the current
>      >>               level of a user along with the clearance level so that
>      >>         mls_systemlow
>      >>               is no longer considered contained in mls_systemhigh.
>      >>
>      >>               Signed-off-by: Harry Ciao
>     <qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com>
>      >>         <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>>>
>      >>
>      >>         This was to prevent a user from logging in at a level
>     below their
>      >>         authorized range, in the unusual scenario where the
>     user's low
>      >>         level was
>      >>         not s0/systemlow.
>      >>
>      >>          >
>      >>          > Ted
>      >>          >
>      >>          >
>      >>
>      >>
>     ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
>      >>
>      >>          >
>      >>          > import selinux
>      >>          >
>      >>          > SECCLASS_CONTEXT =
>     selinux.string_to_security_class("context")
>      >>          > CONTEXT__CONTAINS =
>      >>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
>      >>          > SECCLASS_FILE = selinux.string_to_security_class("file")
>      >>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE,
>     "read")
>      >>          >
>      >>          > raw_con1 = "user_u:user_r:user_t:s1"
>      >>          > raw_con2 = "user_u:user_r:user_t:s0"
>      >>          >
>      >>          > avd = selinux.av_decision()
>      >>          > selinux.avc_reset()
>      >>          > try:
>      >>          >      rc = selinux.security_compute_av_raw(raw_con1,
>     raw_con2,
>      >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>      >>          >      if rc < 0:
>      >>          >          print("selinux.security_compute_av_raw
>     failed for %s
>      >>         %s" %
>      >>          > (raw_con1, raw_con2))
>      >>          >      if (avd.allowed & CONTEXT__CONTAINS) ==
>      >> CONTEXT__CONTAINS:
>      >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>      >>          >      else:
>      >>          >          print("%s does not dominate %s" % (raw_con1,
>      >> raw_con2))
>      >>          > except OSError, ex:
>      >>          >      print "exception calling
>      >>         selinux.security_compute_av_raw", ex
>      >>          >
>      >>          > avd = selinux.av_decision()
>      >>          > selinux.avc_reset()
>      >>          > try:
>      >>          >      rc = selinux.security_compute_av_raw(raw_con1,
>     raw_con2,
>      >>          > SECCLASS_FILE, FILE__READ, avd)
>      >>          >      if rc < 0:
>      >>          >          print("selinux.security_compute_av_raw
>     failed for %s
>      >>         %s" %
>      >>          > (raw_con1, raw_con2))
>      >>          >      if (avd.allowed & FILE__READ) == FILE__READ:
>      >>          >          print("%s dominates %s" % (raw_con1, raw_con2))
>      >>          >      else:
>      >>          >          print("%s does not dominate %s" % (raw_con1,
>      >> raw_con2))
>      >>          >
>      >>          > except OSError:
>      >>          >      print "exception calling
>      >>         selinux.security_compute_av_raw", ex
>      >>          >
>      >>          >
>      >>          >
>      >>          > _______________________________________________
>      >>          > Selinux mailing list
>      >>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
>     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>>
>      >>          > To unsubscribe, send email to
>     Selinux-leave@tycho.nsa.gov <mailto:Selinux-leave@tycho.nsa.gov>
>      >>         <mailto:Selinux-leave@tycho.nsa.gov
>     <mailto:Selinux-leave@tycho.nsa.gov>>.
>      >>          > To get help, send an email containing "help" to
>      >> Selinux-request@tycho.nsa.gov <mailto:Selinux-request@tycho.nsa.gov>
>      >>         <mailto:Selinux-request@tycho.nsa.gov
>     <mailto:Selinux-request@tycho.nsa.gov>>.
>      >>          >
>      >>
>      >
> 

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 03:29 PM, Stephen Smalley wrote:
> On 09/11/2018 02:49 PM, Ted Toth wrote:
>> Yes I too noticed the translate permission but couldn't find any info 
>> related to it intended purpose. Regarding CIL unfortunately I have 
>> zero experience with it but I've installed the compiler and started 
>> reading through https://github.com/SELinuxProject/cil/wiki (any other 
>> pointers to useful info would be appreciated). I have written lots of 
>> policy would it be possible to add a class/permissions/mlsconstraints 
>> in an old-fashion policy module?
> 
> The older binary modules didn't support those kinds of statements 
> outside of the base module.  Try this:
> $ cat > mcstrans.cil <<EOF
> ; define a mcstrans class with one permission color_use
> (class mcstrans (color_use))
> ; allow all domains mcstrans color_use permission to themselves
> (allow domain self (mcstrans (color_use)))
> ; only allow mcstrans color_use permission when h1 dominates h2
> (mlsconstrain (mcstrans (color_use)) (dom h1 h2))
> ; append the new mcstrans class to the end after all others
> (classorder (unordered mcstrans))
> EOF
> 
> $ sudo semodule -i mcstrans.cil
> 
> Then try performing permission checks with "mcstrans" as your class and 
> "color_use" as your permission, between a domain and itself, with 
> different levels.

BTW, an easy way to find CIL syntax for something is to look at how it 
is done in the base module.  You can extract a copy of that via
semodule -c -E base, then bring up base.cil in your favorite editor/viewer.

Re: MLS dominance check behavior on el7

[Ted Toth]

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

That's awesome and now it's got me thinking about other classes/permissions
that we could implement. Can cil macros can be referenced in .te/.if files?


On Tue, Sep 11, 2018 at 2:27 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 09/11/2018 02:49 PM, Ted Toth wrote:
> > Yes I too noticed the translate permission but couldn't find any info
> > related to it intended purpose. Regarding CIL unfortunately I have zero
> > experience with it but I've installed the compiler and started reading
> > through https://github.com/SELinuxProject/cil/wiki (any other pointers
> > to useful info would be appreciated). I have written lots of policy
> > would it be possible to add a class/permissions/mlsconstraints in an
> > old-fashion policy module?
>
> The older binary modules didn't support those kinds of statements
> outside of the base module.  Try this:
> $ cat > mcstrans.cil <<EOF
> ; define a mcstrans class with one permission color_use
> (class mcstrans (color_use))
> ; allow all domains mcstrans color_use permission to themselves
> (allow domain self (mcstrans (color_use)))
> ; only allow mcstrans color_use permission when h1 dominates h2
> (mlsconstrain (mcstrans (color_use)) (dom h1 h2))
> ; append the new mcstrans class to the end after all others
> (classorder (unordered mcstrans))
> EOF
>
> $ sudo semodule -i mcstrans.cil
>
> Then try performing permission checks with "mcstrans" as your class and
> "color_use" as your permission, between a domain and itself, with
> different levels.
>
> >
> > On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley <sds@tycho.nsa.gov
> > <mailto:sds@tycho.nsa.gov>> wrote:
> >
> >     On 09/11/2018 10:41 AM, Stephen Smalley wrote:
> >      > On 09/10/2018 06:30 PM, Ted Toth wrote:
> >      >> mcstrans mcscolor.c also uses the same logic I'd been using to
> >     check
> >      >> dominance so this too will no longer function as expected on
> >     el7. Do
> >      >> you any suggestions for doing a 'generic' (one not tied to a
> >     specific
> >      >> resource class) dominance check in lieu of context contains?
> >      >
> >      > You should probably define your own permission with its own
> >     constraint
> >      > to avoid depending on the base policy's particular constraint
> >      > definitions.  Certainly for your own code.  For mcstrans, mcscolor
> >      > probably ought to be switched to using at least a separate
> >     permission in
> >      > the context class if not its own class to avoid overloading the
> >     meaning
> >      > with pam_selinux's usage (or vice versa, but likely harder to
> change
> >      > pam_selinux at this point).
> >      >
> >      > It is possible to define an entirely new class, its permissions,
> >     and its
> >      > mls constraints via a CIL module IIUC, without needing to change
> the
> >      > base policy.
> >      >
> >      > I don't think you can add a permission to an existing class via a
> >     CIL
> >      > module currently, unfortunately, so you can't just extend the
> >     context
> >      > class without modifying the base policy.  So it may be easier to
> >     define
> >      > an entirely new class.
> >      >
> >      > The class and permission ought to be specific to the usage.  For
> >      > example, mcstrans could have its own class (mcstrans) with its own
> >      > permissions (e.g. color_match or color_use or ...) that abstract
> >     away
> >      > the logical check being performed.  Dominance checks performed for
> >      > different reasons ought to use different permissions so that one
> can
> >      > distinguish what TE pairs are allowed them.
> >      >
> >      > Your code could likewise define and use its own class and
> permission.
> >      >
> >      > Does that make sense?
> >
> >     BTW, I noticed there is another permission ("translate") defined in
> the
> >     context class and its constraint is ((h1 dom h2) or (t1 ==
> >     mlstranslate)).  I would have guessed that it was intended as a
> >     front-end service check over what processes could request context
> >     translations from mcstrans or what contexts they could translate,
> but I
> >     don't see it being used in mcstrans anywhere.  Is this a legacy thing
> >     from early setransd/mcstransd days?  There is a TODO comment in
> >     mcstrans
> >     process_request() that suggests there was an intent to perform a
> >     dominance check between the requester context and the specified
> >     context,
> >     but that's not implemented.  Appears to be allowed in current policy
> >     for
> >     all domains to the setrans_t domain itself.
> >
> >      >
> >      >>
> >      >> Ted
> >      >>
> >      >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth <txtoth@gmail.com
> >     <mailto:txtoth@gmail.com>
> >      >> <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>> wrote:
> >      >>
> >      >>     Understood, thanks.
> >      >>
> >      >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
> >     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
> >      >>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>>
> wrote:
> >      >>
> >      >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
> >      >>          > We currently have code running on el6 that does a MLS
> >      >>         dominance check by
> >      >>          > calling security_compute_av_raw with the security
> >     object class
> >      >>          > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as
> >     you can
> >      >>         see in the
> >      >>          > python code below. When I run this code on el6 s1
> >     dominates
> >      >>         s0 however
> >      >>          > when I run the same code on el7 s1 does not dominate
> >     s0. On
> >      >>         both systems
> >      >>          > the file read dominance check works as expected. Can
> >     anyone
> >      >>         help me
> >      >>          > understand why the context contains check does not
> >     work the
> >      >>         same on both
> >      >>          > systems?
> >      >>
> >      >>         That would depend entirely on how the constraint is
> >     written in
> >      >> the
> >      >>         policy.  I assume this is with the -mls policy on both?
> >     seinfo
> >      >>         --constrain | grep -C1 context would show you the
> >     constraint
> >      >> in the
> >      >>         kernel policy.
> >      >>
> >      >>         Looks like refpolicy defines it as:
> >      >>         mlsconstrain context contains
> >      >>                   (( h1 dom h2 ) and ( l1 domby l2));
> >      >>
> >      >>         The 2nd part of the constraint was introduced by:
> >      >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
> >      >>         Author: Harry Ciao <qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>
> >      >>         <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>>>
> >      >>         Date:   Tue Feb 15 10:16:32 2011 +0800
> >      >>
> >      >>               l1 domby l2 for contains MLS constraint
> >      >>
> >      >>               As identified by Stephan Smalley, the current MLS
> >      >>         constraint for the
> >      >>               contains permission of the context class should
> >     consider
> >      >>         the current
> >      >>               level of a user along with the clearance level so
> that
> >      >>         mls_systemlow
> >      >>               is no longer considered contained in
> mls_systemhigh.
> >      >>
> >      >>               Signed-off-by: Harry Ciao
> >     <qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com>
> >      >>         <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>>>
> >      >>
> >      >>         This was to prevent a user from logging in at a level
> >     below their
> >      >>         authorized range, in the unusual scenario where the
> >     user's low
> >      >>         level was
> >      >>         not s0/systemlow.
> >      >>
> >      >>          >
> >      >>          > Ted
> >      >>          >
> >      >>          >
> >      >>
> >      >>
> >
>  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >
> >      >>
> >      >>          >
> >      >>          > import selinux
> >      >>          >
> >      >>          > SECCLASS_CONTEXT =
> >     selinux.string_to_security_class("context")
> >      >>          > CONTEXT__CONTAINS =
> >      >>         selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains")
> >      >>          > SECCLASS_FILE =
> selinux.string_to_security_class("file")
> >      >>          > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE,
> >     "read")
> >      >>          >
> >      >>          > raw_con1 = "user_u:user_r:user_t:s1"
> >      >>          > raw_con2 = "user_u:user_r:user_t:s0"
> >      >>          >
> >      >>          > avd = selinux.av_decision()
> >      >>          > selinux.avc_reset()
> >      >>          > try:
> >      >>          >      rc = selinux.security_compute_av_raw(raw_con1,
> >     raw_con2,
> >      >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
> >      >>          >      if rc < 0:
> >      >>          >          print("selinux.security_compute_av_raw
> >     failed for %s
> >      >>         %s" %
> >      >>          > (raw_con1, raw_con2))
> >      >>          >      if (avd.allowed & CONTEXT__CONTAINS) ==
> >      >> CONTEXT__CONTAINS:
> >      >>          >          print("%s dominates %s" % (raw_con1,
> raw_con2))
> >      >>          >      else:
> >      >>          >          print("%s does not dominate %s" % (raw_con1,
> >      >> raw_con2))
> >      >>          > except OSError, ex:
> >      >>          >      print "exception calling
> >      >>         selinux.security_compute_av_raw", ex
> >      >>          >
> >      >>          > avd = selinux.av_decision()
> >      >>          > selinux.avc_reset()
> >      >>          > try:
> >      >>          >      rc = selinux.security_compute_av_raw(raw_con1,
> >     raw_con2,
> >      >>          > SECCLASS_FILE, FILE__READ, avd)
> >      >>          >      if rc < 0:
> >      >>          >          print("selinux.security_compute_av_raw
> >     failed for %s
> >      >>         %s" %
> >      >>          > (raw_con1, raw_con2))
> >      >>          >      if (avd.allowed & FILE__READ) == FILE__READ:
> >      >>          >          print("%s dominates %s" % (raw_con1,
> raw_con2))
> >      >>          >      else:
> >      >>          >          print("%s does not dominate %s" % (raw_con1,
> >      >> raw_con2))
> >      >>          >
> >      >>          > except OSError:
> >      >>          >      print "exception calling
> >      >>         selinux.security_compute_av_raw", ex
> >      >>          >
> >      >>          >
> >      >>          >
> >      >>          > _______________________________________________
> >      >>          > Selinux mailing list
> >      >>          > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
> >     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>>
> >      >>          > To unsubscribe, send email to
> >     Selinux-leave@tycho.nsa.gov <mailto:Selinux-leave@tycho.nsa.gov>
> >      >>         <mailto:Selinux-leave@tycho.nsa.gov
> >     <mailto:Selinux-leave@tycho.nsa.gov>>.
> >      >>          > To get help, send an email containing "help" to
> >      >> Selinux-request@tycho.nsa.gov <mailto:
> Selinux-request@tycho.nsa.gov>
> >      >>         <mailto:Selinux-request@tycho.nsa.gov
> >     <mailto:Selinux-request@tycho.nsa.gov>>.
> >      >>          >
> >      >>
> >      >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 18488 bytes --]

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 04:59 PM, Ted Toth wrote:
> That's awesome and now it's got me thinking about other 
> classes/permissions that we could implement. Can cil macros can be 
> referenced in .te/.if files?

Not sure I understand your question.  You can't directly embed cil 
statements in .te/.if files.  However, if you define a class/permission 
in a .cil module, you can certainly specify a require on it and use it 
from a conventional .te/.if module, ala:
$ cat > usemcstrans.te <<EOF
policy_module(usemcstrans, 1.0)

require {
	class mcstrans { color_use };
	attribute domain;
}

allow domain self:mcstrans color_use;
EOF

$ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
$ sudo semodule -i usemcstrans.pp

> On Tue, Sep 11, 2018 at 2:27 PM Stephen Smalley <sds@tycho.nsa.gov 
> <mailto:sds@tycho.nsa.gov>> wrote:
> 
>     On 09/11/2018 02:49 PM, Ted Toth wrote:
>      > Yes I too noticed the translate permission but couldn't find any
>     info
>      > related to it intended purpose. Regarding CIL unfortunately I
>     have zero
>      > experience with it but I've installed the compiler and started
>     reading
>      > through https://github.com/SELinuxProject/cil/wiki (any other
>     pointers
>      > to useful info would be appreciated). I have written lots of policy
>      > would it be possible to add a class/permissions/mlsconstraints in an
>      > old-fashion policy module?
> 
>     The older binary modules didn't support those kinds of statements
>     outside of the base module.  Try this:
>     $ cat > mcstrans.cil <<EOF
>     ; define a mcstrans class with one permission color_use
>     (class mcstrans (color_use))
>     ; allow all domains mcstrans color_use permission to themselves
>     (allow domain self (mcstrans (color_use)))
>     ; only allow mcstrans color_use permission when h1 dominates h2
>     (mlsconstrain (mcstrans (color_use)) (dom h1 h2))
>     ; append the new mcstrans class to the end after all others
>     (classorder (unordered mcstrans))
>     EOF
> 
>     $ sudo semodule -i mcstrans.cil
> 
>     Then try performing permission checks with "mcstrans" as your class and
>     "color_use" as your permission, between a domain and itself, with
>     different levels.
> 
>      >
>      > On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley
>     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
>      > <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>> wrote:
>      >
>      >     On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>      >      > On 09/10/2018 06:30 PM, Ted Toth wrote:
>      >      >> mcstrans mcscolor.c also uses the same logic I'd been
>     using to
>      >     check
>      >      >> dominance so this too will no longer function as expected on
>      >     el7. Do
>      >      >> you any suggestions for doing a 'generic' (one not tied to a
>      >     specific
>      >      >> resource class) dominance check in lieu of context contains?
>      >      >
>      >      > You should probably define your own permission with its own
>      >     constraint
>      >      > to avoid depending on the base policy's particular constraint
>      >      > definitions.  Certainly for your own code.  For mcstrans,
>     mcscolor
>      >      > probably ought to be switched to using at least a separate
>      >     permission in
>      >      > the context class if not its own class to avoid
>     overloading the
>      >     meaning
>      >      > with pam_selinux's usage (or vice versa, but likely harder
>     to change
>      >      > pam_selinux at this point).
>      >      >
>      >      > It is possible to define an entirely new class, its
>     permissions,
>      >     and its
>      >      > mls constraints via a CIL module IIUC, without needing to
>     change the
>      >      > base policy.
>      >      >
>      >      > I don't think you can add a permission to an existing
>     class via a
>      >     CIL
>      >      > module currently, unfortunately, so you can't just extend the
>      >     context
>      >      > class without modifying the base policy.  So it may be
>     easier to
>      >     define
>      >      > an entirely new class.
>      >      >
>      >      > The class and permission ought to be specific to the
>     usage.  For
>      >      > example, mcstrans could have its own class (mcstrans) with
>     its own
>      >      > permissions (e.g. color_match or color_use or ...) that
>     abstract
>      >     away
>      >      > the logical check being performed.  Dominance checks
>     performed for
>      >      > different reasons ought to use different permissions so
>     that one can
>      >      > distinguish what TE pairs are allowed them.
>      >      >
>      >      > Your code could likewise define and use its own class and
>     permission.
>      >      >
>      >      > Does that make sense?
>      >
>      >     BTW, I noticed there is another permission ("translate")
>     defined in the
>      >     context class and its constraint is ((h1 dom h2) or (t1 ==
>      >     mlstranslate)).  I would have guessed that it was intended as a
>      >     front-end service check over what processes could request context
>      >     translations from mcstrans or what contexts they could
>     translate, but I
>      >     don't see it being used in mcstrans anywhere.  Is this a
>     legacy thing
>      >     from early setransd/mcstransd days?  There is a TODO comment in
>      >     mcstrans
>      >     process_request() that suggests there was an intent to perform a
>      >     dominance check between the requester context and the specified
>      >     context,
>      >     but that's not implemented.  Appears to be allowed in current
>     policy
>      >     for
>      >     all domains to the setrans_t domain itself.
>      >
>      >      >
>      >      >>
>      >      >> Ted
>      >      >>
>      >      >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth
>     <txtoth@gmail.com <mailto:txtoth@gmail.com>
>      >     <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>
>      >      >> <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>
>     <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>>> wrote:
>      >      >>
>      >      >>     Understood, thanks.
>      >      >>
>      >      >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
>      >     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>
>      >      >>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>>> wrote:
>      >      >>
>      >      >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
>      >      >>          > We currently have code running on el6 that
>     does a MLS
>      >      >>         dominance check by
>      >      >>          > calling security_compute_av_raw with the security
>      >     object class
>      >      >>          > SECCLASS_CONTEXT with permission
>     CONTEXT__CONTAINS as
>      >     you can
>      >      >>         see in the
>      >      >>          > python code below. When I run this code on el6 s1
>      >     dominates
>      >      >>         s0 however
>      >      >>          > when I run the same code on el7 s1 does not
>     dominate
>      >     s0. On
>      >      >>         both systems
>      >      >>          > the file read dominance check works as
>     expected. Can
>      >     anyone
>      >      >>         help me
>      >      >>          > understand why the context contains check does not
>      >     work the
>      >      >>         same on both
>      >      >>          > systems?
>      >      >>
>      >      >>         That would depend entirely on how the constraint is
>      >     written in
>      >      >> the
>      >      >>         policy.  I assume this is with the -mls policy on
>     both?
>      >     seinfo
>      >      >>         --constrain | grep -C1 context would show you the
>      >     constraint
>      >      >> in the
>      >      >>         kernel policy.
>      >      >>
>      >      >>         Looks like refpolicy defines it as:
>      >      >>         mlsconstrain context contains
>      >      >>                   (( h1 dom h2 ) and ( l1 domby l2));
>      >      >>
>      >      >>         The 2nd part of the constraint was introduced by:
>      >      >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
>      >      >>         Author: Harry Ciao <qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>
>      >     <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>>
>      >      >>         <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>
>      >     <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>>>>
>      >      >>         Date:   Tue Feb 15 10:16:32 2011 +0800
>      >      >>
>      >      >>               l1 domby l2 for contains MLS constraint
>      >      >>
>      >      >>               As identified by Stephan Smalley, the
>     current MLS
>      >      >>         constraint for the
>      >      >>               contains permission of the context class should
>      >     consider
>      >      >>         the current
>      >      >>               level of a user along with the clearance
>     level so that
>      >      >>         mls_systemlow
>      >      >>               is no longer considered contained in
>     mls_systemhigh.
>      >      >>
>      >      >>               Signed-off-by: Harry Ciao
>      >     <qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com>
>     <mailto:qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com>>
>      >      >>         <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>
>      >     <mailto:qingtao.cao@windriver.com
>     <mailto:qingtao.cao@windriver.com>>>>
>      >      >>
>      >      >>         This was to prevent a user from logging in at a level
>      >     below their
>      >      >>         authorized range, in the unusual scenario where the
>      >     user's low
>      >      >>         level was
>      >      >>         not s0/systemlow.
>      >      >>
>      >      >>          >
>      >      >>          > Ted
>      >      >>          >
>      >      >>          >
>      >      >>
>      >      >>
>      >   
>       ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>      >
>      >      >>
>      >      >>          >
>      >      >>          > import selinux
>      >      >>          >
>      >      >>          > SECCLASS_CONTEXT =
>      >     selinux.string_to_security_class("context")
>      >      >>          > CONTEXT__CONTAINS =
>      >      >>         selinux.string_to_av_perm(SECCLASS_CONTEXT,
>     "contains")
>      >      >>          > SECCLASS_FILE =
>     selinux.string_to_security_class("file")
>      >      >>          > FILE__READ =
>     selinux.string_to_av_perm(SECCLASS_FILE,
>      >     "read")
>      >      >>          >
>      >      >>          > raw_con1 = "user_u:user_r:user_t:s1"
>      >      >>          > raw_con2 = "user_u:user_r:user_t:s0"
>      >      >>          >
>      >      >>          > avd = selinux.av_decision()
>      >      >>          > selinux.avc_reset()
>      >      >>          > try:
>      >      >>          >      rc =
>     selinux.security_compute_av_raw(raw_con1,
>      >     raw_con2,
>      >      >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
>      >      >>          >      if rc < 0:
>      >      >>          >          print("selinux.security_compute_av_raw
>      >     failed for %s
>      >      >>         %s" %
>      >      >>          > (raw_con1, raw_con2))
>      >      >>          >      if (avd.allowed & CONTEXT__CONTAINS) ==
>      >      >> CONTEXT__CONTAINS:
>      >      >>          >          print("%s dominates %s" % (raw_con1,
>     raw_con2))
>      >      >>          >      else:
>      >      >>          >          print("%s does not dominate %s" %
>     (raw_con1,
>      >      >> raw_con2))
>      >      >>          > except OSError, ex:
>      >      >>          >      print "exception calling
>      >      >>         selinux.security_compute_av_raw", ex
>      >      >>          >
>      >      >>          > avd = selinux.av_decision()
>      >      >>          > selinux.avc_reset()
>      >      >>          > try:
>      >      >>          >      rc =
>     selinux.security_compute_av_raw(raw_con1,
>      >     raw_con2,
>      >      >>          > SECCLASS_FILE, FILE__READ, avd)
>      >      >>          >      if rc < 0:
>      >      >>          >          print("selinux.security_compute_av_raw
>      >     failed for %s
>      >      >>         %s" %
>      >      >>          > (raw_con1, raw_con2))
>      >      >>          >      if (avd.allowed & FILE__READ) == FILE__READ:
>      >      >>          >          print("%s dominates %s" % (raw_con1,
>     raw_con2))
>      >      >>          >      else:
>      >      >>          >          print("%s does not dominate %s" %
>     (raw_con1,
>      >      >> raw_con2))
>      >      >>          >
>      >      >>          > except OSError:
>      >      >>          >      print "exception calling
>      >      >>         selinux.security_compute_av_raw", ex
>      >      >>          >
>      >      >>          >
>      >      >>          >
>      >      >>          > _______________________________________________
>      >      >>          > Selinux mailing list
>      >      >>          > Selinux@tycho.nsa.gov
>     <mailto:Selinux@tycho.nsa.gov> <mailto:Selinux@tycho.nsa.gov
>     <mailto:Selinux@tycho.nsa.gov>>
>      >     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
>     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>>>
>      >      >>          > To unsubscribe, send email to
>      > Selinux-leave@tycho.nsa.gov <mailto:Selinux-leave@tycho.nsa.gov>
>     <mailto:Selinux-leave@tycho.nsa.gov
>     <mailto:Selinux-leave@tycho.nsa.gov>>
>      >      >>         <mailto:Selinux-leave@tycho.nsa.gov
>     <mailto:Selinux-leave@tycho.nsa.gov>
>      >     <mailto:Selinux-leave@tycho.nsa.gov
>     <mailto:Selinux-leave@tycho.nsa.gov>>>.
>      >      >>          > To get help, send an email containing "help" to
>      >      >> Selinux-request@tycho.nsa.gov
>     <mailto:Selinux-request@tycho.nsa.gov>
>     <mailto:Selinux-request@tycho.nsa.gov
>     <mailto:Selinux-request@tycho.nsa.gov>>
>      >      >>         <mailto:Selinux-request@tycho.nsa.gov
>     <mailto:Selinux-request@tycho.nsa.gov>
>      >     <mailto:Selinux-request@tycho.nsa.gov
>     <mailto:Selinux-request@tycho.nsa.gov>>>.
>      >      >>          >
>      >      >>
>      >      >
>      >
> 

Re: MLS dominance check behavior on el7

[Ted Toth]

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

On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 09/11/2018 04:59 PM, Ted Toth wrote:
> > That's awesome and now it's got me thinking about other
> > classes/permissions that we could implement. Can cil macros can be
> > referenced in .te/.if files?
>
> Not sure I understand your question.  You can't directly embed cil
> statements in .te/.if files.  However, if you define a class/permission
> in a .cil module, you can certainly specify a require on it and use it
> from a conventional .te/.if module, ala:
> $ cat > usemcstrans.te <<EOF
> policy_module(usemcstrans, 1.0)
>
> require {
>         class mcstrans { color_use };
>         attribute domain;
> }
>
> allow domain self:mcstrans color_use;
> EOF
>
> $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> $ sudo semodule -i usemcstrans.pp
>
>
If the cil contained:

(macro use_color (type caller) (allow caller self mcstrans (color_use)))

then in x.te can I use the macro:

type x_t;
use_color(x_t)


> On Tue, Sep 11, 2018 at 2:27 PM Stephen Smalley <sds@tycho.nsa.gov
> > <mailto:sds@tycho.nsa.gov>> wrote:
> >
> >     On 09/11/2018 02:49 PM, Ted Toth wrote:
> >      > Yes I too noticed the translate permission but couldn't find any
> >     info
> >      > related to it intended purpose. Regarding CIL unfortunately I
> >     have zero
> >      > experience with it but I've installed the compiler and started
> >     reading
> >      > through https://github.com/SELinuxProject/cil/wiki (any other
> >     pointers
> >      > to useful info would be appreciated). I have written lots of
> policy
> >      > would it be possible to add a class/permissions/mlsconstraints in
> an
> >      > old-fashion policy module?
> >
> >     The older binary modules didn't support those kinds of statements
> >     outside of the base module.  Try this:
> >     $ cat > mcstrans.cil <<EOF
> >     ; define a mcstrans class with one permission color_use
> >     (class mcstrans (color_use))
> >     ; allow all domains mcstrans color_use permission to themselves
> >     (allow domain self (mcstrans (color_use)))
> >     ; only allow mcstrans color_use permission when h1 dominates h2
> >     (mlsconstrain (mcstrans (color_use)) (dom h1 h2))
> >     ; append the new mcstrans class to the end after all others
> >     (classorder (unordered mcstrans))
> >     EOF
> >
> >     $ sudo semodule -i mcstrans.cil
> >
> >     Then try performing permission checks with "mcstrans" as your class
> and
> >     "color_use" as your permission, between a domain and itself, with
> >     different levels.
> >
> >      >
> >      > On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley
> >     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
> >      > <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>> wrote:
> >      >
> >      >     On 09/11/2018 10:41 AM, Stephen Smalley wrote:
> >      >      > On 09/10/2018 06:30 PM, Ted Toth wrote:
> >      >      >> mcstrans mcscolor.c also uses the same logic I'd been
> >     using to
> >      >     check
> >      >      >> dominance so this too will no longer function as expected
> on
> >      >     el7. Do
> >      >      >> you any suggestions for doing a 'generic' (one not tied
> to a
> >      >     specific
> >      >      >> resource class) dominance check in lieu of context
> contains?
> >      >      >
> >      >      > You should probably define your own permission with its own
> >      >     constraint
> >      >      > to avoid depending on the base policy's particular
> constraint
> >      >      > definitions.  Certainly for your own code.  For mcstrans,
> >     mcscolor
> >      >      > probably ought to be switched to using at least a separate
> >      >     permission in
> >      >      > the context class if not its own class to avoid
> >     overloading the
> >      >     meaning
> >      >      > with pam_selinux's usage (or vice versa, but likely harder
> >     to change
> >      >      > pam_selinux at this point).
> >      >      >
> >      >      > It is possible to define an entirely new class, its
> >     permissions,
> >      >     and its
> >      >      > mls constraints via a CIL module IIUC, without needing to
> >     change the
> >      >      > base policy.
> >      >      >
> >      >      > I don't think you can add a permission to an existing
> >     class via a
> >      >     CIL
> >      >      > module currently, unfortunately, so you can't just extend
> the
> >      >     context
> >      >      > class without modifying the base policy.  So it may be
> >     easier to
> >      >     define
> >      >      > an entirely new class.
> >      >      >
> >      >      > The class and permission ought to be specific to the
> >     usage.  For
> >      >      > example, mcstrans could have its own class (mcstrans) with
> >     its own
> >      >      > permissions (e.g. color_match or color_use or ...) that
> >     abstract
> >      >     away
> >      >      > the logical check being performed.  Dominance checks
> >     performed for
> >      >      > different reasons ought to use different permissions so
> >     that one can
> >      >      > distinguish what TE pairs are allowed them.
> >      >      >
> >      >      > Your code could likewise define and use its own class and
> >     permission.
> >      >      >
> >      >      > Does that make sense?
> >      >
> >      >     BTW, I noticed there is another permission ("translate")
> >     defined in the
> >      >     context class and its constraint is ((h1 dom h2) or (t1 ==
> >      >     mlstranslate)).  I would have guessed that it was intended as
> a
> >      >     front-end service check over what processes could request
> context
> >      >     translations from mcstrans or what contexts they could
> >     translate, but I
> >      >     don't see it being used in mcstrans anywhere.  Is this a
> >     legacy thing
> >      >     from early setransd/mcstransd days?  There is a TODO comment
> in
> >      >     mcstrans
> >      >     process_request() that suggests there was an intent to
> perform a
> >      >     dominance check between the requester context and the
> specified
> >      >     context,
> >      >     but that's not implemented.  Appears to be allowed in current
> >     policy
> >      >     for
> >      >     all domains to the setrans_t domain itself.
> >      >
> >      >      >
> >      >      >>
> >      >      >> Ted
> >      >      >>
> >      >      >> On Mon, Sep 10, 2018 at 1:19 PM Ted Toth
> >     <txtoth@gmail.com <mailto:txtoth@gmail.com>
> >      >     <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>
> >      >      >> <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>
> >     <mailto:txtoth@gmail.com <mailto:txtoth@gmail.com>>>> wrote:
> >      >      >>
> >      >      >>     Understood, thanks.
> >      >      >>
> >      >      >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
> >      >     <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
> >     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>
> >      >      >>     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>
> >     <mailto:sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>>>> wrote:
> >      >      >>
> >      >      >>         On 09/10/2018 01:13 PM, Ted Toth wrote:
> >      >      >>          > We currently have code running on el6 that
> >     does a MLS
> >      >      >>         dominance check by
> >      >      >>          > calling security_compute_av_raw with the
> security
> >      >     object class
> >      >      >>          > SECCLASS_CONTEXT with permission
> >     CONTEXT__CONTAINS as
> >      >     you can
> >      >      >>         see in the
> >      >      >>          > python code below. When I run this code on el6
> s1
> >      >     dominates
> >      >      >>         s0 however
> >      >      >>          > when I run the same code on el7 s1 does not
> >     dominate
> >      >     s0. On
> >      >      >>         both systems
> >      >      >>          > the file read dominance check works as
> >     expected. Can
> >      >     anyone
> >      >      >>         help me
> >      >      >>          > understand why the context contains check does
> not
> >      >     work the
> >      >      >>         same on both
> >      >      >>          > systems?
> >      >      >>
> >      >      >>         That would depend entirely on how the constraint
> is
> >      >     written in
> >      >      >> the
> >      >      >>         policy.  I assume this is with the -mls policy on
> >     both?
> >      >     seinfo
> >      >      >>         --constrain | grep -C1 context would show you the
> >      >     constraint
> >      >      >> in the
> >      >      >>         kernel policy.
> >      >      >>
> >      >      >>         Looks like refpolicy defines it as:
> >      >      >>         mlsconstrain context contains
> >      >      >>                   (( h1 dom h2 ) and ( l1 domby l2));
> >      >      >>
> >      >      >>         The 2nd part of the constraint was introduced by:
> >      >      >>         commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc
> >      >      >>         Author: Harry Ciao <qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>
> >      >     <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>>
> >      >      >>         <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>
> >      >     <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>>>>
> >      >      >>         Date:   Tue Feb 15 10:16:32 2011 +0800
> >      >      >>
> >      >      >>               l1 domby l2 for contains MLS constraint
> >      >      >>
> >      >      >>               As identified by Stephan Smalley, the
> >     current MLS
> >      >      >>         constraint for the
> >      >      >>               contains permission of the context class
> should
> >      >     consider
> >      >      >>         the current
> >      >      >>               level of a user along with the clearance
> >     level so that
> >      >      >>         mls_systemlow
> >      >      >>               is no longer considered contained in
> >     mls_systemhigh.
> >      >      >>
> >      >      >>               Signed-off-by: Harry Ciao
> >      >     <qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com>
> >     <mailto:qingtao.cao@windriver.com <mailto:qingtao.cao@windriver.com
> >>
> >      >      >>         <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>
> >      >     <mailto:qingtao.cao@windriver.com
> >     <mailto:qingtao.cao@windriver.com>>>>
> >      >      >>
> >      >      >>         This was to prevent a user from logging in at a
> level
> >      >     below their
> >      >      >>         authorized range, in the unusual scenario where
> the
> >      >     user's low
> >      >      >>         level was
> >      >      >>         not s0/systemlow.
> >      >      >>
> >      >      >>          >
> >      >      >>          > Ted
> >      >      >>          >
> >      >      >>          >
> >      >      >>
> >      >      >>
> >      >
> >
>  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >      >
> >      >      >>
> >      >      >>          >
> >      >      >>          > import selinux
> >      >      >>          >
> >      >      >>          > SECCLASS_CONTEXT =
> >      >     selinux.string_to_security_class("context")
> >      >      >>          > CONTEXT__CONTAINS =
> >      >      >>         selinux.string_to_av_perm(SECCLASS_CONTEXT,
> >     "contains")
> >      >      >>          > SECCLASS_FILE =
> >     selinux.string_to_security_class("file")
> >      >      >>          > FILE__READ =
> >     selinux.string_to_av_perm(SECCLASS_FILE,
> >      >     "read")
> >      >      >>          >
> >      >      >>          > raw_con1 = "user_u:user_r:user_t:s1"
> >      >      >>          > raw_con2 = "user_u:user_r:user_t:s0"
> >      >      >>          >
> >      >      >>          > avd = selinux.av_decision()
> >      >      >>          > selinux.avc_reset()
> >      >      >>          > try:
> >      >      >>          >      rc =
> >     selinux.security_compute_av_raw(raw_con1,
> >      >     raw_con2,
> >      >      >>          > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd)
> >      >      >>          >      if rc < 0:
> >      >      >>          >          print("selinux.security_compute_av_raw
> >      >     failed for %s
> >      >      >>         %s" %
> >      >      >>          > (raw_con1, raw_con2))
> >      >      >>          >      if (avd.allowed & CONTEXT__CONTAINS) ==
> >      >      >> CONTEXT__CONTAINS:
> >      >      >>          >          print("%s dominates %s" % (raw_con1,
> >     raw_con2))
> >      >      >>          >      else:
> >      >      >>          >          print("%s does not dominate %s" %
> >     (raw_con1,
> >      >      >> raw_con2))
> >      >      >>          > except OSError, ex:
> >      >      >>          >      print "exception calling
> >      >      >>         selinux.security_compute_av_raw", ex
> >      >      >>          >
> >      >      >>          > avd = selinux.av_decision()
> >      >      >>          > selinux.avc_reset()
> >      >      >>          > try:
> >      >      >>          >      rc =
> >     selinux.security_compute_av_raw(raw_con1,
> >      >     raw_con2,
> >      >      >>          > SECCLASS_FILE, FILE__READ, avd)
> >      >      >>          >      if rc < 0:
> >      >      >>          >          print("selinux.security_compute_av_raw
> >      >     failed for %s
> >      >      >>         %s" %
> >      >      >>          > (raw_con1, raw_con2))
> >      >      >>          >      if (avd.allowed & FILE__READ) ==
> FILE__READ:
> >      >      >>          >          print("%s dominates %s" % (raw_con1,
> >     raw_con2))
> >      >      >>          >      else:
> >      >      >>          >          print("%s does not dominate %s" %
> >     (raw_con1,
> >      >      >> raw_con2))
> >      >      >>          >
> >      >      >>          > except OSError:
> >      >      >>          >      print "exception calling
> >      >      >>         selinux.security_compute_av_raw", ex
> >      >      >>          >
> >      >      >>          >
> >      >      >>          >
> >      >      >>          > _______________________________________________
> >      >      >>          > Selinux mailing list
> >      >      >>          > Selinux@tycho.nsa.gov
> >     <mailto:Selinux@tycho.nsa.gov> <mailto:Selinux@tycho.nsa.gov
> >     <mailto:Selinux@tycho.nsa.gov>>
> >      >     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
> >     <mailto:Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>>>
> >      >      >>          > To unsubscribe, send email to
> >      > Selinux-leave@tycho.nsa.gov <mailto:Selinux-leave@tycho.nsa.gov>
> >     <mailto:Selinux-leave@tycho.nsa.gov
> >     <mailto:Selinux-leave@tycho.nsa.gov>>
> >      >      >>         <mailto:Selinux-leave@tycho.nsa.gov
> >     <mailto:Selinux-leave@tycho.nsa.gov>
> >      >     <mailto:Selinux-leave@tycho.nsa.gov
> >     <mailto:Selinux-leave@tycho.nsa.gov>>>.
> >      >      >>          > To get help, send an email containing "help" to
> >      >      >> Selinux-request@tycho.nsa.gov
> >     <mailto:Selinux-request@tycho.nsa.gov>
> >     <mailto:Selinux-request@tycho.nsa.gov
> >     <mailto:Selinux-request@tycho.nsa.gov>>
> >      >      >>         <mailto:Selinux-request@tycho.nsa.gov
> >     <mailto:Selinux-request@tycho.nsa.gov>
> >      >     <mailto:Selinux-request@tycho.nsa.gov
> >     <mailto:Selinux-request@tycho.nsa.gov>>>.
> >      >      >>          >
> >      >      >>
> >      >      >
> >      >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 27203 bytes --]

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/12/2018 09:26 AM, Ted Toth wrote:
> 
> 
> On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov 
> <mailto:sds@tycho.nsa.gov>> wrote:
> 
>     On 09/11/2018 04:59 PM, Ted Toth wrote:
>      > That's awesome and now it's got me thinking about other
>      > classes/permissions that we could implement. Can cil macros can be
>      > referenced in .te/.if files?
> 
>     Not sure I understand your question.  You can't directly embed cil
>     statements in .te/.if files.  However, if you define a class/permission
>     in a .cil module, you can certainly specify a require on it and use it
>     from a conventional .te/.if module, ala:
>     $ cat > usemcstrans.te <<EOF
>     policy_module(usemcstrans, 1.0)
> 
>     require {
>              class mcstrans { color_use };
>              attribute domain;
>     }
> 
>     allow domain self:mcstrans color_use;
>     EOF
> 
>     $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
>     $ sudo semodule -i usemcstrans.pp
> 
> 
> If the cil contained:
> 
> (macro use_color (type caller) (allow caller self mcstrans (color_use)))
> 
> then in x.te can I use the macro:
> 
> type x_t;
> use_color(x_t)

Sorry, no.  The macros used in .te/.if files are just m4 definitions 
handled at the preprocessing stage, not a feature of the module 
language.  The CIL macros are directly supported by the CIL compiler, 
but they won't be visible to the module compiler.  Also, you are missing 
several parentheses above (I'm not fond of the lisp-like syntax myself). 
  In a CIL module, I think the correct syntax would be:

(macro use_color ((type caller)) (allow caller self (mcstrans (color_use))))

(call use_color(x_t))

Or you could define a m4 macro in an .if file and use that in a .te 
file.  Or both.

Re: MLS dominance check behavior on el7

[Dominick Grift]

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

On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
> On 09/12/2018 09:26 AM, Ted Toth wrote:
> > 
> > 
> > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov
> > <mailto:sds@tycho.nsa.gov>> wrote:
> > 
> >     On 09/11/2018 04:59 PM, Ted Toth wrote:
> >      > That's awesome and now it's got me thinking about other
> >      > classes/permissions that we could implement. Can cil macros can be
> >      > referenced in .te/.if files?
> > 
> >     Not sure I understand your question.  You can't directly embed cil
> >     statements in .te/.if files.  However, if you define a class/permission
> >     in a .cil module, you can certainly specify a require on it and use it
> >     from a conventional .te/.if module, ala:
> >     $ cat > usemcstrans.te <<EOF
> >     policy_module(usemcstrans, 1.0)
> > 
> >     require {
> >              class mcstrans { color_use };
> >              attribute domain;
> >     }
> > 
> >     allow domain self:mcstrans color_use;
> >     EOF
> > 
> >     $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> >     $ sudo semodule -i usemcstrans.pp
> > 
> > 
> > If the cil contained:
> > 
> > (macro use_color (type caller) (allow caller self mcstrans (color_use)))
> > 
> > then in x.te can I use the macro:
> > 
> > type x_t;
> > use_color(x_t)
> 
> Sorry, no.  The macros used in .te/.if files are just m4 definitions handled
> at the preprocessing stage, not a feature of the module language.  The CIL
> macros are directly supported by the CIL compiler, but they won't be visible
> to the module compiler.  Also, you are missing several parentheses above
> (I'm not fond of the lisp-like syntax myself).  In a CIL module, I think the
> correct syntax would be:
> 
> (macro use_color ((type caller)) (allow caller self (mcstrans (color_use))))
> 
> (call use_color(x_t))
> 
> Or you could define a m4 macro in an .if file and use that in a .te file.
> Or both.
> 

Ideally you would have all of your policy written in CIL or in a high-level language that was designed to leverage CIL.

My DSSP2 policy is a CIL-only policy. In there I also leverage unordered classes, Meaning that for example if you remove or disable the mcstrans module then you automatically also remove or disable  the access vectors that mcstrans manages.

minimal:

https://github.com/DefenSec/dssp2-minimal

standard (my personal policy based on top of minimal):

https://github.com/DefenSec/dssp2-standard/commits/master

DSSP2 does not support enforcement of confidentiality though

> _______________________________________________
> 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: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: MLS dominance check behavior on el7

[Ted Toth]

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

On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift <dac.override@gmail.com>
wrote:

> On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
> > On 09/12/2018 09:26 AM, Ted Toth wrote:
> > >
> > >
> > > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov
> > > <mailto:sds@tycho.nsa.gov>> wrote:
> > >
> > >     On 09/11/2018 04:59 PM, Ted Toth wrote:
> > >      > That's awesome and now it's got me thinking about other
> > >      > classes/permissions that we could implement. Can cil macros can
> be
> > >      > referenced in .te/.if files?
> > >
> > >     Not sure I understand your question.  You can't directly embed cil
> > >     statements in .te/.if files.  However, if you define a
> class/permission
> > >     in a .cil module, you can certainly specify a require on it and
> use it
> > >     from a conventional .te/.if module, ala:
> > >     $ cat > usemcstrans.te <<EOF
> > >     policy_module(usemcstrans, 1.0)
> > >
> > >     require {
> > >              class mcstrans { color_use };
> > >              attribute domain;
> > >     }
> > >
> > >     allow domain self:mcstrans color_use;
> > >     EOF
> > >
> > >     $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> > >     $ sudo semodule -i usemcstrans.pp
> > >
> > >
> > > If the cil contained:
> > >
> > > (macro use_color (type caller) (allow caller self mcstrans
> (color_use)))
> > >
> > > then in x.te can I use the macro:
> > >
> > > type x_t;
> > > use_color(x_t)
> >
> > Sorry, no.  The macros used in .te/.if files are just m4 definitions
> handled
> > at the preprocessing stage, not a feature of the module language.  The
> CIL
> > macros are directly supported by the CIL compiler, but they won't be
> visible
> > to the module compiler.  Also, you are missing several parentheses above
> > (I'm not fond of the lisp-like syntax myself).  In a CIL module, I think
> the
> > correct syntax would be:
> >
> > (macro use_color ((type caller)) (allow caller self (mcstrans
> (color_use))))
> >
> > (call use_color(x_t))
> >
> > Or you could define a m4 macro in an .if file and use that in a .te file.
> > Or both.
> >
>
> Ideally you would have all of your policy written in CIL or in a
> high-level language that was designed to leverage CIL.
>

Unfortunately I/we don't live in an ideal world :( but thanks for the
pointers.


>
> My DSSP2 policy is a CIL-only policy. In there I also leverage unordered
> classes, Meaning that for example if you remove or disable the mcstrans
> module then you automatically also remove or disable  the access vectors
> that mcstrans manages.
>
> minimal:
>
> https://github.com/DefenSec/dssp2-minimal
>
> standard (my personal policy based on top of minimal):
>
> https://github.com/DefenSec/dssp2-standard/commits/master
>
> DSSP2 does not support enforcement of confidentiality though
>
> > _______________________________________________
> > 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: Type: text/html, Size: 4937 bytes --]

Re: MLS dominance check behavior on el7

[Ted Toth]

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

On Wed, Sep 12, 2018 at 9:57 AM Ted Toth <txtoth@gmail.com> wrote:

>
>
> On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift <dac.override@gmail.com>
> wrote:
>
>> On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
>> > On 09/12/2018 09:26 AM, Ted Toth wrote:
>> > >
>> > >
>> > > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov
>> > > <mailto:sds@tycho.nsa.gov>> wrote:
>> > >
>> > >     On 09/11/2018 04:59 PM, Ted Toth wrote:
>> > >      > That's awesome and now it's got me thinking about other
>> > >      > classes/permissions that we could implement. Can cil macros
>> can be
>> > >      > referenced in .te/.if files?
>> > >
>> > >     Not sure I understand your question.  You can't directly embed cil
>> > >     statements in .te/.if files.  However, if you define a
>> class/permission
>> > >     in a .cil module, you can certainly specify a require on it and
>> use it
>> > >     from a conventional .te/.if module, ala:
>> > >     $ cat > usemcstrans.te <<EOF
>> > >     policy_module(usemcstrans, 1.0)
>> > >
>> > >     require {
>> > >              class mcstrans { color_use };
>> > >              attribute domain;
>> > >     }
>> > >
>> > >     allow domain self:mcstrans color_use;
>> > >     EOF
>> > >
>> > >     $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
>> > >     $ sudo semodule -i usemcstrans.pp
>> > >
>> > >
>> > > If the cil contained:
>> > >
>> > > (macro use_color (type caller) (allow caller self mcstrans
>> (color_use)))
>> > >
>> > > then in x.te can I use the macro:
>> > >
>> > > type x_t;
>> > > use_color(x_t)
>> >
>> > Sorry, no.  The macros used in .te/.if files are just m4 definitions
>> handled
>> > at the preprocessing stage, not a feature of the module language.  The
>> CIL
>> > macros are directly supported by the CIL compiler, but they won't be
>> visible
>> > to the module compiler.  Also, you are missing several parentheses above
>> > (I'm not fond of the lisp-like syntax myself).  In a CIL module, I
>> think the
>> > correct syntax would be:
>> >
>> > (macro use_color ((type caller)) (allow caller self (mcstrans
>> (color_use))))
>> >
>> > (call use_color(x_t))
>> >
>> > Or you could define a m4 macro in an .if file and use that in a .te
>> file.
>> > Or both.
>> >
>>
>> Ideally you would have all of your policy written in CIL or in a
>> high-level language that was designed to leverage CIL.
>>
>
> Unfortunately I/we don't live in an ideal world :( but thanks for the
> pointers.
>
>
>>
>> My DSSP2 policy is a CIL-only policy. In there I also leverage unordered
>> classes, Meaning that for example if you remove or disable the mcstrans
>> module then you automatically also remove or disable  the access vectors
>> that mcstrans manages.
>>
>> minimal:
>>
>> https://github.com/DefenSec/dssp2-minimal
>>
>> standard (my personal policy based on top of minimal):
>>
>> https://github.com/DefenSec/dssp2-standard/commits/master
>>
>> DSSP2 does not support enforcement of confidentiality though
>>
>> > _______________________________________________
>> > 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
>>
>
I added a security class and permission using the following cil:
(block mcstrans
    (typeattributeset cil_gen_require  setrans_t)
    (typeattributeset cil_gen_require user_t)
    (class level_color (pick_using_dominance))
    (classorder (unordered level_color))

    (mlsconstrain (level_color (pick_using_dominance)) (dom h1 h2))

    (allow setrans_t self (level_color (pick_using_dominance))))

and this works for the mcscolor code I changed to use it. However I wrote
some python code to test the class/permission (using
security_compute_av_raw) and ran it before adding an allow rule for the
python code type and no avc was generated as I'd expected. Is there
anything different about adding a security class this way that would affect
avc generation?

[-- Attachment #2: Type: text/html, Size: 6263 bytes --]

Re: MLS dominance check behavior on el7

[Dominick Grift]

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

On Fri, Sep 14, 2018 at 04:18:29PM -0500, Ted Toth wrote:
> On Wed, Sep 12, 2018 at 9:57 AM Ted Toth <txtoth@gmail.com> wrote:
> 
> >
> >
> > On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift <dac.override@gmail.com>
> > wrote:
> >
> >> On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
> >> > On 09/12/2018 09:26 AM, Ted Toth wrote:
> >> > >
> >> > >
> >> > > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov
> >> > > <mailto:sds@tycho.nsa.gov>> wrote:
> >> > >
> >> > >     On 09/11/2018 04:59 PM, Ted Toth wrote:
> >> > >      > That's awesome and now it's got me thinking about other
> >> > >      > classes/permissions that we could implement. Can cil macros
> >> can be
> >> > >      > referenced in .te/.if files?
> >> > >
> >> > >     Not sure I understand your question.  You can't directly embed cil
> >> > >     statements in .te/.if files.  However, if you define a
> >> class/permission
> >> > >     in a .cil module, you can certainly specify a require on it and
> >> use it
> >> > >     from a conventional .te/.if module, ala:
> >> > >     $ cat > usemcstrans.te <<EOF
> >> > >     policy_module(usemcstrans, 1.0)
> >> > >
> >> > >     require {
> >> > >              class mcstrans { color_use };
> >> > >              attribute domain;
> >> > >     }
> >> > >
> >> > >     allow domain self:mcstrans color_use;
> >> > >     EOF
> >> > >
> >> > >     $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> >> > >     $ sudo semodule -i usemcstrans.pp
> >> > >
> >> > >
> >> > > If the cil contained:
> >> > >
> >> > > (macro use_color (type caller) (allow caller self mcstrans
> >> (color_use)))
> >> > >
> >> > > then in x.te can I use the macro:
> >> > >
> >> > > type x_t;
> >> > > use_color(x_t)
> >> >
> >> > Sorry, no.  The macros used in .te/.if files are just m4 definitions
> >> handled
> >> > at the preprocessing stage, not a feature of the module language.  The
> >> CIL
> >> > macros are directly supported by the CIL compiler, but they won't be
> >> visible
> >> > to the module compiler.  Also, you are missing several parentheses above
> >> > (I'm not fond of the lisp-like syntax myself).  In a CIL module, I
> >> think the
> >> > correct syntax would be:
> >> >
> >> > (macro use_color ((type caller)) (allow caller self (mcstrans
> >> (color_use))))
> >> >
> >> > (call use_color(x_t))
> >> >
> >> > Or you could define a m4 macro in an .if file and use that in a .te
> >> file.
> >> > Or both.
> >> >
> >>
> >> Ideally you would have all of your policy written in CIL or in a
> >> high-level language that was designed to leverage CIL.
> >>
> >
> > Unfortunately I/we don't live in an ideal world :( but thanks for the
> > pointers.
> >
> >
> >>
> >> My DSSP2 policy is a CIL-only policy. In there I also leverage unordered
> >> classes, Meaning that for example if you remove or disable the mcstrans
> >> module then you automatically also remove or disable  the access vectors
> >> that mcstrans manages.
> >>
> >> minimal:
> >>
> >> https://github.com/DefenSec/dssp2-minimal
> >>
> >> standard (my personal policy based on top of minimal):
> >>
> >> https://github.com/DefenSec/dssp2-standard/commits/master
> >>
> >> DSSP2 does not support enforcement of confidentiality though
> >>
> >> > _______________________________________________
> >> > 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
> >>
> >
> I added a security class and permission using the following cil:
> (block mcstrans
>     (typeattributeset cil_gen_require  setrans_t)
>     (typeattributeset cil_gen_require user_t)
>     (class level_color (pick_using_dominance))
>     (classorder (unordered level_color))
> 
>     (mlsconstrain (level_color (pick_using_dominance)) (dom h1 h2))
> 
>     (allow setrans_t self (level_color (pick_using_dominance))))
> 
> and this works for the mcscolor code I changed to use it. However I wrote
> some python code to test the class/permission (using
> security_compute_av_raw) and ran it before adding an allow rule for the
> python code type and no avc was generated as I'd expected. Is there
> anything different about adding a security class this way that would affect
> avc generation?

Did you look for type=user_avc messages? Is setrans using "selinux_access_check()" instead of "avc_has_perm()"?

> _______________________________________________
> 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: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: MLS dominance check behavior on el7

[Joe Nall]

> On Sep 11, 2018, at 1:29 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>> mcstrans mcscolor.c also uses the same logic I'd been using to check dominance so this too will no longer function as expected on el7. Do you any suggestions for doing a 'generic' (one not tied to a specific resource class) dominance check in lieu of context contains?
>> You should probably define your own permission with its own constraint to avoid depending on the base policy's particular constraint definitions.  Certainly for your own code.  For mcstrans, mcscolor probably ought to be switched to using at least a separate permission in the context class if not its own class to avoid overloading the meaning with pam_selinux's usage (or vice versa, but likely harder to change pam_selinux at this point).
>> It is possible to define an entirely new class, its permissions, and its mls constraints via a CIL module IIUC, without needing to change the base policy.
>> I don't think you can add a permission to an existing class via a CIL module currently, unfortunately, so you can't just extend the context class without modifying the base policy.  So it may be easier to define an entirely new class.
>> The class and permission ought to be specific to the usage.  For example, mcstrans could have its own class (mcstrans) with its own permissions (e.g. color_match or color_use or ...) that abstract away the logical check being performed.  Dominance checks performed for different reasons ought to use different permissions so that one can distinguish what TE pairs are allowed them.
>> Your code could likewise define and use its own class and permission.
>> Does that make sense?
> 
> BTW, I noticed there is another permission ("translate") defined in the context class and its constraint is ((h1 dom h2) or (t1 == mlstranslate)).  I would have guessed that it was intended as a front-end service check over what processes could request context translations from mcstrans or what contexts they could translate, but I don't see it being used in mcstrans anywhere.  Is this a legacy thing from early setransd/mcstransd days?  There is a TODO comment in mcstrans process_request() that suggests there was an intent to perform a dominance check between the requester context and the specified context, but that's not implemented.  Appears to be allowed in current policy for all domains to the setrans_t domain itself.

I think 'translate' predates my mcstransd work and dates from the original TCS implementation. There is an argument to implement that constraint, but we've been operating without it for so long it does not seem worthwhile.

joe

Re: MLS dominance check behavior on el7

[Stephen Smalley]

On 09/11/2018 03:04 PM, Joe Nall wrote:
> 
> 
>> On Sep 11, 2018, at 1:29 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>> mcstrans mcscolor.c also uses the same logic I'd been using to check dominance so this too will no longer function as expected on el7. Do you any suggestions for doing a 'generic' (one not tied to a specific resource class) dominance check in lieu of context contains?
>>> You should probably define your own permission with its own constraint to avoid depending on the base policy's particular constraint definitions.  Certainly for your own code.  For mcstrans, mcscolor probably ought to be switched to using at least a separate permission in the context class if not its own class to avoid overloading the meaning with pam_selinux's usage (or vice versa, but likely harder to change pam_selinux at this point).
>>> It is possible to define an entirely new class, its permissions, and its mls constraints via a CIL module IIUC, without needing to change the base policy.
>>> I don't think you can add a permission to an existing class via a CIL module currently, unfortunately, so you can't just extend the context class without modifying the base policy.  So it may be easier to define an entirely new class.
>>> The class and permission ought to be specific to the usage.  For example, mcstrans could have its own class (mcstrans) with its own permissions (e.g. color_match or color_use or ...) that abstract away the logical check being performed.  Dominance checks performed for different reasons ought to use different permissions so that one can distinguish what TE pairs are allowed them.
>>> Your code could likewise define and use its own class and permission.
>>> Does that make sense?
>>
>> BTW, I noticed there is another permission ("translate") defined in the context class and its constraint is ((h1 dom h2) or (t1 == mlstranslate)).  I would have guessed that it was intended as a front-end service check over what processes could request context translations from mcstrans or what contexts they could translate, but I don't see it being used in mcstrans anywhere.  Is this a legacy thing from early setransd/mcstransd days?  There is a TODO comment in mcstrans process_request() that suggests there was an intent to perform a dominance check between the requester context and the specified context, but that's not implemented.  Appears to be allowed in current policy for all domains to the setrans_t domain itself.
> 
> I think 'translate' predates my mcstransd work and dates from the original TCS implementation. There is an argument to implement that constraint, but we've been operating without it for so long it does not seem worthwhile.

Well, I guess we ought to either implement it or delete the permission 
definition from refpolicy.

Re: MLS dominance check behavior on el7

[Chris PeBenito]

On 09/11/2018 04:20 PM, Stephen Smalley wrote:
> On 09/11/2018 03:04 PM, Joe Nall wrote:
>>
>>
>>> On Sep 11, 2018, at 1:29 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>> mcstrans mcscolor.c also uses the same logic I'd been using to 
>>>>> check dominance so this too will no longer function as expected on 
>>>>> el7. Do you any suggestions for doing a 'generic' (one not tied to 
>>>>> a specific resource class) dominance check in lieu of context 
>>>>> contains?
>>>> You should probably define your own permission with its own 
>>>> constraint to avoid depending on the base policy's particular 
>>>> constraint definitions.  Certainly for your own code.  For mcstrans, 
>>>> mcscolor probably ought to be switched to using at least a separate 
>>>> permission in the context class if not its own class to avoid 
>>>> overloading the meaning with pam_selinux's usage (or vice versa, but 
>>>> likely harder to change pam_selinux at this point).
>>>> It is possible to define an entirely new class, its permissions, and 
>>>> its mls constraints via a CIL module IIUC, without needing to change 
>>>> the base policy.
>>>> I don't think you can add a permission to an existing class via a 
>>>> CIL module currently, unfortunately, so you can't just extend the 
>>>> context class without modifying the base policy.  So it may be 
>>>> easier to define an entirely new class.
>>>> The class and permission ought to be specific to the usage.  For 
>>>> example, mcstrans could have its own class (mcstrans) with its own 
>>>> permissions (e.g. color_match or color_use or ...) that abstract 
>>>> away the logical check being performed.  Dominance checks performed 
>>>> for different reasons ought to use different permissions so that one 
>>>> can distinguish what TE pairs are allowed them.
>>>> Your code could likewise define and use its own class and permission.
>>>> Does that make sense?
>>>
>>> BTW, I noticed there is another permission ("translate") defined in 
>>> the context class and its constraint is ((h1 dom h2) or (t1 == 
>>> mlstranslate)).  I would have guessed that it was intended as a 
>>> front-end service check over what processes could request context 
>>> translations from mcstrans or what contexts they could translate, but 
>>> I don't see it being used in mcstrans anywhere.  Is this a legacy 
>>> thing from early setransd/mcstransd days?  There is a TODO comment in 
>>> mcstrans process_request() that suggests there was an intent to 
>>> perform a dominance check between the requester context and the 
>>> specified context, but that's not implemented.  Appears to be allowed 
>>> in current policy for all domains to the setrans_t domain itself.
>>
>> I think 'translate' predates my mcstransd work and dates from the 
>> original TCS implementation. There is an argument to implement that 
>> constraint, but we've been operating without it for so long it does 
>> not seem worthwhile.
> 
> Well, I guess we ought to either implement it or delete the permission 
> definition from refpolicy.

I'm fine removing it.  It's just the translate permission that is 
unused, not the whole class, correct?

-- 
Chris PeBenito

Re: MLS dominance check behavior on el7

[Chris PeBenito]

On 10/04/2018 05:01 PM, Stephen Smalley wrote:
> On 09/30/2018 10:43 AM, Chris PeBenito wrote:
>> On 09/11/2018 04:20 PM, Stephen Smalley wrote:
>>> On 09/11/2018 03:04 PM, Joe Nall wrote:
>>>>> On Sep 11, 2018, at 1:29 PM, Stephen Smalley <sds@tycho.nsa.gov> 
>>>>> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>>>>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>> BTW, I noticed there is another permission ("translate") defined in 
>>>>> the context class and its constraint is ((h1 dom h2) or (t1 == 
>>>>> mlstranslate)).  I would have guessed that it was intended as a 
>>>>> front-end service check over what processes could request context 
>>>>> translations from mcstrans or what contexts they could translate, 
>>>>> but I don't see it being used in mcstrans anywhere.  Is this a 
>>>>> legacy thing from early setransd/mcstransd days?  There is a TODO 
>>>>> comment in mcstrans process_request() that suggests there was an 
>>>>> intent to perform a dominance check between the requester context 
>>>>> and the specified context, but that's not implemented.  Appears to 
>>>>> be allowed in current policy for all domains to the setrans_t 
>>>>> domain itself.
>>>>
>>>> I think 'translate' predates my mcstransd work and dates from the 
>>>> original TCS implementation. There is an argument to implement that 
>>>> constraint, but we've been operating without it for so long it does 
>>>> not seem worthwhile.
>>>
>>> Well, I guess we ought to either implement it or delete the 
>>> permission definition from refpolicy.
>>
>> I'm fine removing it.  It's just the translate permission that is 
>> unused, not the whole class, correct?
> 
> Correct. Only caveat is that removing translate will change the 
> permission index of contains, which could break a running mcstransd upon 
> a policy reload (doesn't use selinux_check_access or even the avc; won't 
> flush the class/perm string mapping on a reload automatically).

Good point.  I think I'll remove all the rules and constraints and then
rename the permission to unused or unused_perm.  Then the indices will 
be stable, but it will be clear the perm is unused.

-- 
Chris PeBenito

Re: MLS dominance check behavior on el7

[Chad Hanson]

On Fri, Oct 05, 2018 at 04:05:13PM -0400, Chris PeBenito wrote:
> On 10/04/2018 05:01 PM, Stephen Smalley wrote:
> >On 09/30/2018 10:43 AM, Chris PeBenito wrote:
> >>On 09/11/2018 04:20 PM, Stephen Smalley wrote:
> >>>On 09/11/2018 03:04 PM, Joe Nall wrote:
> >>>>>On Sep 11, 2018, at 1:29 PM, Stephen Smalley
> >>>>><sds@tycho.nsa.gov> On 09/11/2018 10:41 AM, Stephen
> >>>>>Smalley wrote:
> >>>>>>On 09/10/2018 06:30 PM, Ted Toth wrote:
> >>>>>BTW, I noticed there is another permission ("translate")
> >>>>>defined in the context class and its constraint is ((h1
> >>>>>dom h2) or (t1 == mlstranslate)).  I would have guessed
> >>>>>that it was intended as a front-end service check over
> >>>>>what processes could request context translations from
> >>>>>mcstrans or what contexts they could translate, but I
> >>>>>don't see it being used in mcstrans anywhere.  Is this a
> >>>>>legacy thing from early setransd/mcstransd days?  There is
> >>>>>a TODO comment in mcstrans process_request() that suggests
> >>>>>there was an intent to perform a dominance check between
> >>>>>the requester context and the specified context, but
> >>>>>that's not implemented.  Appears to be allowed in current
> >>>>>policy for all domains to the setrans_t domain itself.
> >>>>
> >>>>I think 'translate' predates my mcstransd work and dates
> >>>>from the original TCS implementation. There is an argument
> >>>>to implement that constraint, but we've been operating
> >>>>without it for so long it does not seem worthwhile.
> >>>
> >>>Well, I guess we ought to either implement it or delete the
> >>>permission definition from refpolicy.
> >>
> >>I'm fine removing it.  It's just the translate permission that
> >>is unused, not the whole class, correct?
> >
> >Correct. Only caveat is that removing translate will change the
> >permission index of contains, which could break a running
> >mcstransd upon a policy reload (doesn't use selinux_check_access
> >or even the avc; won't flush the class/perm string mapping on a
> >reload automatically).
> 
> Good point.  I think I'll remove all the rules and constraints and then
> rename the permission to unused or unused_perm.  Then the indices
> will be stable, but it will be clear the perm is unused.

We are not using this permission anymore, so I concur in removing it as
well.

-Chad