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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Stephen Smalley]

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


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



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Dominick Grift]

On Fri, Sep 14, 2018 at 04:18:29PM -0500, Ted Toth wrote:
> On Wed, Sep 12, 2018 at 9:57 AM Ted Toth  wrote:
> 
> >
> >
> > On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift 
> > 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  >> > > > 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 < >> > > 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-le...@tycho.nsa.gov.
> >> > To get help, send an email containing "help" to
> >> selinux-requ...@tycho.nsa.gov.
> >>
> >> --
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get=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-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: MLS dominance check behavior on el7

[Ted Toth]

On Wed, Sep 12, 2018 at 9:57 AM Ted Toth  wrote:

>
>
> On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift 
> 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 > > > > 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 <> > > 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-le...@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> selinux-requ...@tycho.nsa.gov.
>>
>> --
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get=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?
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Ted Toth]

On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift 
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  > > > 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 < > > 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-le...@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> selinux-requ...@tycho.nsa.gov.
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Dominick Grift]

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  > > 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 < > 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-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Ted Toth]

On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley  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 < 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  > > 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 < > ; 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
> > mailto:s...@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 

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 > 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 <
 > On Tue, Sep 11, 2018 at 1:27 PM Stephen Smalley
mailto:s...@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
mailto:txt...@gmail.com>
 >     >
 >      >> 

Re: MLS dominance check behavior on el7

[Ted Toth]

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  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 < ; 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  > > 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  > 
> >  >> >> wrote:
> >  >>
> >  >> Understood, thanks.
> >  >>
> >  >> On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
> > mailto:s...@tycho.nsa.gov>
> >  >> 

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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@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 

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 > 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 mailto:txt...@gmail.com>
 >> >> wrote:
 >>
 >>     Understood, thanks.
 >>
 >>     On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley
mailto:s...@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 

Re: MLS dominance check behavior on el7

[Joe Nall]

> On Sep 11, 2018, at 1:29 PM, Stephen Smalley  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



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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  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  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  >> > wrote:
> >>
> >> Understood, thanks.
> >>
> >> On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley  >> > 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  >> >
> >> Date:   Tue Feb 

Re: MLS dominance check behavior on el7

[Ted Toth]

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  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  >> > wrote:
> >>
> >> Understood, thanks.
> >>
> >> On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley  >> > 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  >> >
> >> 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 

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 > wrote:


    Understood, thanks.

    On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley mailto:s...@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 mailto:qingtao@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 mailto:qingtao@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")
 > 

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  wrote:

On 09/11/2018 12:53 PM, Joshua Brindle wrote:


On Tue, Sep 11, 2018 at 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).



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.

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Joshua Brindle]

On Tue, Sep 11, 2018 at 1:33 PM, Stephen Smalley  wrote:
> On 09/11/2018 12:53 PM, Joshua Brindle wrote:
>>
>> On Tue, Sep 11, 2018 at 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).
>>>
>>
>> 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.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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




___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Joshua Brindle]

On Tue, Sep 11, 2018 at 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).
>

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?
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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 > wrote:


Understood, thanks.

On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley mailto:s...@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 mailto:qingtao@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 mailto:qingtao@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:
 >          

Re: MLS dominance check behavior on el7

[Ted Toth]

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  wrote:

> Understood, thanks.
>
> On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley 
> 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 
>> 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 
>>
>> 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-le...@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> selinux-requ...@tycho.nsa.gov.
>> >
>>
>>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: MLS dominance check behavior on el7

[Ted Toth]

Understood, thanks.

On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley  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 
> 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 
>
> 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-le...@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> selinux-requ...@tycho.nsa.gov.
> >
>
>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

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

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-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

MLS dominance check behavior on el7

[Ted Toth]

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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.