generating new type name using CIL macro

generating new type name using CIL macro

[Vit Mojzis]

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

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

Re: generating new type name using CIL macro

[Dominick Grift]

Vit Mojzis <vmojzis@redhat.com> 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)?

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@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: generating new type name using CIL macro

[Vit Mojzis]

Hi Dominick,
thank you for the suggestion. I know about block inheritance, but it 
produces type/role names that are not consistent with refpolicy ("." 
separating the new block name and it's content). My goal is to create 
new SELinux users and corresponding roles and it would be confusing for 
users to switch between roles with different naming schemes (e.g. 
"secadm_r" vs. "customuser.r"). Given that "typeinherit" statements 
don't seem to be supported, I'm trying my luck with macros to replicate 
interfaces.

Thank you,
Vit

On 9/12/23 05:50, Dominick Grift wrote:
> Vit Mojzis <vmojzis@redhat.com> 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)?
> 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
>>

Re: generating new type name using CIL macro

[Dominick Grift]

Vit Mojzis <vmojzis@redhat.com> writes:

> Hi Dominick,
> thank you for the suggestion. I know about block inheritance, but it
> produces type/role names that are not consistent with refpolicy ("."
> separating the new block name and it's content). My goal is to create
> new SELinux users and corresponding roles and it would be confusing
> for users to switch between roles with different naming schemes
> (e.g. "secadm_r" vs. "customuser.r"). Given that "typeinherit"
> statements don't seem to be supported, I'm trying my luck with macros
> to replicate interfaces.

I figured. You could alternatively create an abstraction c.q.
HLL. Depending on your requirements that does not have to be
complicated. Could be some shell, python or M4 that does the templating for
you. Essentially that is what refpolicy2 does with its M4 usage.


>
> Thank you,
> Vit
>
> On 9/12/23 05:50, Dominick Grift wrote:
>> Vit Mojzis <vmojzis@redhat.com> 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)?
>> 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@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: generating new type name using CIL macro

[James Carter]

On Tue, Sep 12, 2023 at 1:19 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Vit Mojzis <vmojzis@redhat.com> 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.

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.

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@defensec.nl (wkd)
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift
> Mastodon: @kcinimod@defensec.nl

Re: generating new type name using CIL macro

[Vit Mojzis]

On 9/12/23 15:13, James Carter wrote:
> On Tue, Sep 12, 2023 at 1:19 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>> Vit Mojzis <vmojzis@redhat.com> 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))

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@defensec.nl (wkd)
>> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>> Dominick Grift
>> Mastodon: @kcinimod@defensec.nl

Re: generating new type name using CIL macro

[James Carter]

On Tue, Sep 12, 2023 at 2:29 PM Vit Mojzis <vmojzis@redhat.com> wrote:
>
>
>
> On 9/12/23 15:13, James Carter wrote:
> > On Tue, Sep 12, 2023 at 1:19 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >> Vit Mojzis <vmojzis@redhat.com> 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))
>
> This installs without any complaints, but the type does not get defined
> and the rule gets silently ignored as well.
>

That is interesting. I'll have to take a look at that.
Thanks for the report.
Jim

> >
> > 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@defensec.nl (wkd)
> >> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> >> Dominick Grift
> >> Mastodon: @kcinimod@defensec.nl
>

Re: generating new type name using CIL macro

[James Carter]

On Tue, Sep 12, 2023 at 2:29 PM Vit Mojzis <vmojzis@redhat.com> wrote:
>
>
>
> On 9/12/23 15:13, James Carter wrote:
> > On Tue, Sep 12, 2023 at 1:19 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >> Vit Mojzis <vmojzis@redhat.com> 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@defensec.nl (wkd)
> >> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> >> Dominick Grift
> >> Mastodon: @kcinimod@defensec.nl
>