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