On Tue, Sep 12, 2023 at 2:29 PM Vit Mojzis <vmojzis@xxxxxxxxxx> wrote:
>
>
>
> On 9/12/23 15:13, James Carter wrote:
> > On Tue, Sep 12, 2023 at 1:19 AM Dominick Grift
> > <dominick.grift@xxxxxxxxxxx> wrote:
> >> Vit Mojzis <vmojzis@xxxxxxxxxx> writes:
> >>
> >>> Hello all,
> >>> while trying to recreate some selinux-policy templates using CIL
> >>> macros I got stuck on creating new type/role/attribute names.
> >>> For example consider ssh_role_template [1], which uses its first
> >>> parameter to create a new type $1_ssh_agent_t.
> >>>
> >>> Is there a way to recreate such functionality in a CIL macro (or
> >>> another CIL feature)?
> > In CIL we wanted to get away from the m4 string mangling. The thought
> > was that a higher-level language could do this if desired.
> > CIL is very restrictive in that all the arguments in a call have to be
> > already defined. You cannot even pass a string that will be used to
> > declare a type--the type must already be defined.
>
> Right, this complicates replicating interfaces even further.
>
> BTW there is no error or warning when passing a string in an attempt to
> define a new entity inside the macro.
> (macro define_type ((string t))
> (type t)
> (allow t t (process (setcap)))
> )
> (call define_type (yolo))
>
So what is going on here is that type t is being declared and that is
completely different from the string t that is a macro parameter.
The allow rule resolves because t is a valid type. As the macro is
written, the "yolo" being passed in is not used. But if you would make
a named type transition rule that takes t as the filename, it would
end up with "yolo".
An error would be produced if you had used (type t) instead of (string
t) in the macro.
There probably should be a warning in the case above.
Jim
> This installs without any complaints, but the type does not get defined
> and the rule gets silently ignored as well.
>
> >
> > As Dominick says below, we thought that blocks and inheritance would
> > replace the string mangling, but, as you note, this does change how
> > the type looks.
>
> Yes, and since that is something I cannot ignore, I'll have to create
> some kind of simple abstraction as Dominick suggested.
>
> Thank you both for the suggestions and explanations, you helped me a
> great deal.
> Vit
>
> >
> > Jim
> >
> >> CIL uses blocks for it implementation of templating. If you want to leverage
> >> native CIL then look into blocks.
> >>
> >> Example:
> >>
> >> cat > mytest.cil <<EOF
> >> (typeattribute foo)
> >>
> >> (block t
> >> (blockabstract t)
> >> (type t)
> >> (typeattributeset .foo t))
> >>
> >> (block bar
> >> (blockinherit t))
> >>
> >> (block baz
> >> (blockinherit t))
> >>
> >> (allow .foo .foo (process (signal)))
> >> EOF
> >>
> >> sudo semodule -i mytest.cil
> >>
> >> seinfo -xafoo
> >>
> >> Type Attributes: 1
> >> attribute foo;
> >> bar.t
> >> baz.t
> >>
> >> sesearch -A -s foo -ds
> >> allow foo foo:process signal;
> >>
> >>> Something along the lines of:
> >>> (macro new_type_macro ((string type_prefix))
> >>> (type (type_prefix)_t)
> >>> )
> >>> which when called (call new_type_macro ("yolo")) would produce
> >>> (type yolo_t)
> >>>
> >>> I searched through CIL reference guide [2] and SELinuxProject CIL wiki
> >>> on github, but didn't find anything close (maybe there is a better
> >>> resource I don't know about).
> >>> I'd appreciate any hints or links to other resources related to CIL macros.
> >>>
> >>> Thank you,
> >>> Vit
> >>>
> >>> [1] -
> >>> https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/services/ssh.if#L301
> >>> [2] -
> >>> https://raw.githubusercontent.com/SELinuxProject/selinux-notebook/main/src/notebook-examples/selinux-policy/cil/CIL_Reference_Guide.pdf
> >>> [3] - https://github.com/SELinuxProject/cil/wiki#macros
> >>>
> >> --
> >> gpg --locate-keys dominick.grift@xxxxxxxxxxx (wkd)
> >> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
> >> Dominick Grift
> >> Mastodon: @kcinimod@xxxxxxxxxxx
>
