Re: cil mlsconstrain
On Tue, Oct 23, 2018 at 9:05 AM Stephen Smalley wrote: > On 10/23/2018 09:56 AM, Ted Toth wrote: > > > > > > On Tue, Oct 23, 2018 at 8:39 AM Stephen Smalley > <mailto:s...@tycho.nsa.gov>> wrote: > > > > On 10/23/2018 09:33 AM, Ted Toth wrote: > > > Is it possible to modify/replace an existing mlsconstrain? In > > playing > > > around I created multiple instances of a mlsconstrain and > > variations of > > > mlsconstrains but haven't figured out how to clean them up as I > get > > > "Error: Unknown keyword delete' when trying to delete my > experiments. > > > > Possibly I misunderstand, but can't you just remove or replace the > > module that defined it previously? > > > > > > We make some changes to several 'x_*' mls constraints which as far as I > > know are not part of a module. > > They have to live in some module, base or otherwise. > You can extract the CIL for the module in which you defined them via > semodule -cE , e.g. semodule -cE base. Then you can edit > them in that base.cil or other file and re-insert the updated one. > > That's what I'll do, thanks. > > > > > > > BTW, selinux mailing list has moved to seli...@vger.kernel.org > > <mailto:seli...@vger.kernel.org>. > > > > Thanks for the reminder now I just need gmail to remember :( > > ___ 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: cil mlsconstrain
On Tue, Oct 23, 2018 at 8:39 AM Stephen Smalley wrote: > On 10/23/2018 09:33 AM, Ted Toth wrote: > > Is it possible to modify/replace an existing mlsconstrain? In playing > > around I created multiple instances of a mlsconstrain and variations of > > mlsconstrains but haven't figured out how to clean them up as I get > > "Error: Unknown keyword delete' when trying to delete my experiments. > > Possibly I misunderstand, but can't you just remove or replace the > module that defined it previously? > We make some changes to several 'x_*' mls constraints which as far as I know are not part of a module. > BTW, selinux mailing list has moved to seli...@vger.kernel.org. > > Thanks for the reminder now I just need gmail to remember :( ___ 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.
cil mlsconstrain
Is it possible to modify/replace an existing mlsconstrain? In playing around I created multiple instances of a mlsconstrain and variations of mlsconstrains but haven't figured out how to clean them up as I get "Error: Unknown keyword delete' when trying to delete my experiments. Ted ___ 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: file context not being set on el7
On Fri, Sep 21, 2018 at 7:21 AM Ted Toth wrote: > > On Fri, Sep 21, 2018 at 3:58 AM Petr Lautrbach > wrote: > >> >> Ted Toth writes: >> >> > I have something very much like the following in an fc file: >> > /usr/lib64/python2\.(6|7)/site-packages/xyz/paste -- >> > gen_context(system_u:object_r:jxyz_exec_t,s0) >> > >> > and I use the same file on el6 and el7. On el6 the file is >> > labeled as >> > specified in the python2.6 directory. However on el7 where the >> > file gets >> > installed into python2.7 the file is not labeled correctly. On >> > el7 >> > `semanage fcontext -l | grep xyz` shows the file context >> > expected but >> > `matchpathcon /usr/lib64/python2.7/site-packages/xyz/paste` does >> > not return >> > the expected context and `restorecon -RFv >> > /usr/lib64/python2.7/site-packages/xyz` has no affect. The type >> > xyz_exec_t >> > exists on both systems. It's probably something stupid I'm doing >> > but I'm >> > just not seeing it. Has anyone else experienced similar issues? >> > >> >> There's equivalency rule /usr/lib64 -> /usr/lib on el7: >> >> # semanage fcontext -a -t tmp_t >> '/usr/lib64/python2\.(6|7)/site-packages/xyz/paste' >> >> ValueError: File spec >> /usr/lib64/python2\.(6|7)/site-packages/xyz/paste conflicts with >> equivalency rule '/usr/lib64 /usr/lib'; Try adding >> '/usr/lib/python2\.(6|7)/site-packages/xyz/paste' instead >> >> >> # semanage fcontext -a -t tmp_t >> '/usr/lib/python2\.(6|7)/site-packages/xyz/paste' >> >> # matchpathcon /usr/lib64/python2.7/site-packages/xyz/paste >> /usr/lib64/python2.7/site-packages/xyz/paste >> system_u:object_r:tmp_t:s0 >> >> >> Petr >> > > Thanks, where is this equivalency rule defined/documented? > /usr/lib(64)?/python... doesn't work either how can I make it backward compatible? ___ 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: file context not being set on el7
On Fri, Sep 21, 2018 at 3:58 AM Petr Lautrbach wrote: > > Ted Toth writes: > > > I have something very much like the following in an fc file: > > /usr/lib64/python2\.(6|7)/site-packages/xyz/paste -- > > gen_context(system_u:object_r:jxyz_exec_t,s0) > > > > and I use the same file on el6 and el7. On el6 the file is > > labeled as > > specified in the python2.6 directory. However on el7 where the > > file gets > > installed into python2.7 the file is not labeled correctly. On > > el7 > > `semanage fcontext -l | grep xyz` shows the file context > > expected but > > `matchpathcon /usr/lib64/python2.7/site-packages/xyz/paste` does > > not return > > the expected context and `restorecon -RFv > > /usr/lib64/python2.7/site-packages/xyz` has no affect. The type > > xyz_exec_t > > exists on both systems. It's probably something stupid I'm doing > > but I'm > > just not seeing it. Has anyone else experienced similar issues? > > > > There's equivalency rule /usr/lib64 -> /usr/lib on el7: > > # semanage fcontext -a -t tmp_t > '/usr/lib64/python2\.(6|7)/site-packages/xyz/paste' > > ValueError: File spec > /usr/lib64/python2\.(6|7)/site-packages/xyz/paste conflicts with > equivalency rule '/usr/lib64 /usr/lib'; Try adding > '/usr/lib/python2\.(6|7)/site-packages/xyz/paste' instead > > > # semanage fcontext -a -t tmp_t > '/usr/lib/python2\.(6|7)/site-packages/xyz/paste' > > # matchpathcon /usr/lib64/python2.7/site-packages/xyz/paste > /usr/lib64/python2.7/site-packages/xyz/paste > system_u:object_r:tmp_t:s0 > > > Petr > Thanks, where is this equivalency rule defined/documented? ___ 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.
file context not being set on el7
I have something very much like the following in an fc file: /usr/lib64/python2\.(6|7)/site-packages/xyz/paste -- gen_context(system_u:object_r:jxyz_exec_t,s0) and I use the same file on el6 and el7. On el6 the file is labeled as specified in the python2.6 directory. However on el7 where the file gets installed into python2.7 the file is not labeled correctly. On el7 `semanage fcontext -l | grep xyz` shows the file context expected but `matchpathcon /usr/lib64/python2.7/site-packages/xyz/paste` does not return the expected context and `restorecon -RFv /usr/lib64/python2.7/site-packages/xyz` has no affect. The type xyz_exec_t exists on both systems. It's probably something stupid I'm doing but I'm just not seeing it. Has anyone else experienced similar issues? Ted ___ 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
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 > > > <mailto:s...@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 <> > > 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
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 > > <mailto:s...@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 < > > 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
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 > <mailto:s...@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 < > ; 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>
> > > <mailto:s...@tycho.nsa.gov <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 y
Re: MLS dominance check behavior on el7
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 > <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 chec
Re: MLS dominance check behavior on el7
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 >> <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 policy on both? seinfo
> >> --constrain | grep -C1 context would show you the constraint
> >> in the
> >> kernel policy.
> >>
> &g
Re: MLS dominance check behavior on el7
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
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.
MLS dominance check behavior on el7
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.
