CIL blockinherit and entering a macro namespace using in

CIL blockinherit and entering a macro namespace using in

[bauen1]

Hello,

After getting my CIL policy to work, I have discovered another problem.

According to the manual
https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/cil_container_statements.md#in
`in` can be used to enter a namespace, including macros.
This works, except when using blockinherit and trying to enter a macro
that was inherited.

My use case would be a base file template with a lot of macros, and
using `in` to add more access to the macros where appropiate.

See the test case below, bauen1


(class process (transition))
(class file (read))
(classorder (unordered process file))

(user kernel_u)
(role kernel_r)
(userrole kernel_u kernel_r)
(type kernel_t)
(roletype kernel_r kernel_t)

(sid kernel)
(sidorder (kernel))

(sensitivity s0)
(sensitivityorder (s0))
(level low (s0))
(level high (s0))
(levelrange lowhigh (low high))
(userlevel kernel_u low)
(userrange kernel_u lowhigh)

(context kernel_context (kernel_u kernel_r kernel_t lowhigh))
(sidcontext kernel kernel_context)

(macro test1
    ((type domain))
    (allow domain self (process (all)))
)

(in test1
    (allow domain self (file (all)))
)

(block a
    (macro test2
        ((type domain))
        (allow domain self (process (all)))
    )

    (in test2
        (allow domain self (file (all)))
    )
)

(block b
    (blockabstract b)
    (macro test3
        ((type domain))
        (allow domain self (process (all)))
    )
)

(block c
    (blockinherit b)

    (in test3
        (allow domain self (file (all)))
    )
)

; In Theory all macros: test1, a.test2, c.test3 should result in the
same code

Re: CIL blockinherit and entering a macro namespace using in

[James Carter]

On Thu, Jun 18, 2020 at 12:17 PM bauen1 <j2468h@googlemail.com> wrote:
>
> Hello,
>
> After getting my CIL policy to work, I have discovered another problem.
>
> According to the manual
> https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/cil_container_statements.md#in
> `in` can be used to enter a namespace, including macros.
> This works, except when using blockinherit and trying to enter a macro
> that was inherited.
>

That is correct. The problem is that "in" is resolved before the
blockinherit. We wanted to keep things simple, so we picked an order
for them to be resolved. There were good arguments for resolving it
the way you would need for your policy, but that is not what was
chosen. Sorry.

Jim


> My use case would be a base file template with a lot of macros, and
> using `in` to add more access to the macros where appropiate.
>
> See the test case below, bauen1
>
>
> (class process (transition))
> (class file (read))
> (classorder (unordered process file))
>
> (user kernel_u)
> (role kernel_r)
> (userrole kernel_u kernel_r)
> (type kernel_t)
> (roletype kernel_r kernel_t)
>
> (sid kernel)
> (sidorder (kernel))
>
> (sensitivity s0)
> (sensitivityorder (s0))
> (level low (s0))
> (level high (s0))
> (levelrange lowhigh (low high))
> (userlevel kernel_u low)
> (userrange kernel_u lowhigh)
>
> (context kernel_context (kernel_u kernel_r kernel_t lowhigh))
> (sidcontext kernel kernel_context)
>
> (macro test1
>     ((type domain))
>     (allow domain self (process (all)))
> )
>
> (in test1
>     (allow domain self (file (all)))
> )
>
> (block a
>     (macro test2
>         ((type domain))
>         (allow domain self (process (all)))
>     )
>
>     (in test2
>         (allow domain self (file (all)))
>     )
> )
>
> (block b
>     (blockabstract b)
>     (macro test3
>         ((type domain))
>         (allow domain self (process (all)))
>     )
> )
>
> (block c
>     (blockinherit b)
>
>     (in test3
>         (allow domain self (file (all)))
>     )
> )
>
> ; In Theory all macros: test1, a.test2, c.test3 should result in the
> same code
>
>