Re: libsepol regressions

[Dominick Grift <dominick.grift@defensec.nl>]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Dominick Grift <dominick.grift@defensec.nl> writes:
>
>> Dominick Grift <dominick.grift@defensec.nl> writes:
>>
>>> Fedora recently decided to pull in various libsepol patches from
>>> master[1]
>
> Here is another simplified take:
>
> Why does this work?
>
> (sid kernel)
> (sidorder (kernel))
> (class CLASS1 (PERM1 PERM2))
> (classorder (unordered CLASS1))
> (block test1
> (type type1)
> (block conf1
> (type type1)))
> (in test1.conf1
> (allow type self (CLASS1 (PERM1))))

Make that type1

>
>> [kcinimod@myguest tests]$ secilc testa.cil
>> [kcinimod@myguest tests]$ seinfo policy.33 -t
>
>> Types: 2
>>   test1.conf1.type1
>>   test1.type1
>> [kcinimod@myguest tests]$
>
> Why does this not work?
>
> (sid kernel)
> (sidorder (kernel))
> (class CLASS2 (PERM1 PERM2))
> (classorder (unordered CLASS2))
> (block template2
> (type type2)
> (allow type2 self (CLASS2 (PERM1)))
> (block conf2
> (type type2)))
> (block test2
> (blockinherit template2))
> (in test2.conf2
> (allow type2 self (CLASS2 (PERM2))))
>
>> [kcinimod@myguest tests]$ secilc testb.cil
>> Failed to resolve in-statement at testb.cil:12
>> Failed to resolve AST
>> Failed to compile cildb: -1
>
> I would like to be able to understand from a user perspective. What is
> the difference between test1.conf1 and test2.conf2? Why can they not
> both be resolved consistently?
>
> What are the implications of this limitation? Does this mean that blocks
> that declare blocks and macros cannot be reliably inherited?
>
> If we are not able to reliably declare blocks and macros inside
> containers then should we be allowed to do this in the first place? And
> what purpose remains there for blockinherit and in given the above?
>
>>
>> Here are two examples (test1.cil and test2.cil)  that I think
>> demonstrate some of my issues. Comment out the ";;the culprit" blocks to see
>> it fail.
>>
>> In the test1.cil scenario I previously was able to get around this by
>> re-declaring the macro.
>>
>> In the test2.cil scenario I previously was able to get around this by
>> re-declaring the block.
>>
>> I do not mind not being allowed to re-declare macros and blocks
>> but then I would appreciate if I could use "in" to insert into them
>> instead. If I cannot either re-declare nor "insert into" then templates
>> become pretty useless due to the limitations.



>>
>>  ---
>>
>> cat > test1.cil <<EOF
>> ;; what is the point of templates when you cannot access them?
>>
>> (sid kernel)
>> (sidorder (kernel))
>> (class CLASS1 (PERM1 PERM2))
>> (classorder (unordered CLASS1))
>>
>> (type type)
>> (typeattribute typeattr) 
>>
>> (block block_a1
>> (block block_a2
>> (blockabstract block_a2)
>> (macro macro_a1 ((type ARG1))
>> (allow ARG1 type (CLASS1 (PERM1))))))
>>
>> (block block_b1
>> (type type)
>> (blockinherit block_a1.block_a2))
>>
>> (block block_c1
>> (type type)
>> (call block_b1.macro_a1 (type)))
>>
>> (block block_d1
>> (type type)
>> (blockinherit block_a1.block_a2))
>>
>> ;;the culprit
>> ;;(in block_d1.macro_a1
>> ;;(allow ARG1 type (CLASS (PERM2))))
>>
>> (block block_e1
>> (type type)
>> (call block_d1.macro_a1 (type)))
>> EOF
>> secilc test1.cil
>>
>>  ---
>>
>> cat > test2.cil <<EOF
>> ;; what is the point of templates when you cannot access them?
>>
>> (sid kernel)
>> (sidorder (kernel))
>> (class CLASS1 (PERM1 PERM2))
>> (classorder (unordered CLASS1))
>>
>> (type type)
>> (typeattribute typeattr) 
>>
>> (block block_a1
>> (type type)
>> (allow type self (CLASS1 (PERM1)))
>> (block block_a2
>> (blockabstract block_a2)
>> (type type)
>> (allow type self (CLASS1 (PERM1)))
>> (block block_a3
>> (type type)
>> (allow type self (CLASS1 (PERM1))))))
>>
>> (block block_b1
>> (blockinherit block_a1.block_a2)
>> (allow type self (CLASS1 (PERM2))))
>>
>> ;;the culprit
>> ;;(in block_b1.block_a3
>> ;;(block block_b2
>> ;;(type type)))
>> EOF
>> secilc test2.cil
>>
>>>
>>> My policy has broken down in various way's. Some changes make sense but
>>> some others I have issues with.
>>>
>>> An example of something I never expected to be allowed in the first
>>> place is re-declarations of blocks and recent changes exposed some instances
>>> where I declared blocks multiple times and got away with it.
>>>
>>> However I also encountered issues that i am not sure how to deal
>>> with.
>>>
>>> re-declarations of macros are no longer allowed:
>>>
>>> Take this example:
>>> https://github.com/DefenSec/dssp5/blob/dev/src/dev/termdev.cil
>>>
>>> Here I inherit a set of macros from the
>>> "file.all_macro_template_chr_files" template and then I override some of these
>>> macros by manually re-declaring them with slighty different content (the
>>> xperm rules are appended).
>>>
>>> This use to be allowed but I am no longer allowed to redeclare macros.
>>>
>>> This would not necessarily be a big problem IF this would instead work:
>>>
>>> diff --git a/src/dev/termdev.cil b/src/dev/termdev.cil
>>> index 1c0fe66..4f067db 100644
>>> --- a/src/dev/termdev.cil
>>> +++ b/src/dev/termdev.cil
>>> @@ -3,21 +3,9 @@
>>>
>>>  (block termdev
>>>
>>> -       (macro appendinherited_all_chr_files ((type ARG1))
>>> -             (allow ARG1 typeattr appendinherited_chr_file)
>>> -             (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>> -
>>> -       (macro readwriteinherited_all_chr_files ((type ARG1))
>>> -             (allow ARG1 typeattr readwriteinherited_chr_file)
>>> -             (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>> -
>>>         (macro type ((type ARG1))
>>>               (typeattributeset typeattr ARG1))
>>>
>>> -       (macro writeinherited_all_chr_files ((type ARG1))
>>> -             (allow ARG1 typeattr writeinherited_chr_file)
>>> -             (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>> -
>>>         (typeattribute typeattr)
>>>
>>>         (blockinherit .file.all_macro_template_chr_files)
>>> @@ -33,3 +21,12 @@
>>>
>>>               (allow typeattr termdev.typeatt
>>>                      (chr_file (not (execmod mounton))))))
>>> +
>>> +(in termdev.appendinherited_all_chr_files
>>> +    (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>> +
>>> +(in termdev.readwriteinherited_all_chr_files
>>> +    (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>> +
>>> +(in termdev.writeinherited_all_chr_files
>>> +    (allowx ARG1 typeattr (ioctl chr_file (not (0x5412)))))
>>>
>>> But the above in-statements cannot be resolved.
>>>
>>> This is not the only instance where this approach does not work. I also
>>> have templates that declare blocks. I use to be allowed to re-declare
>>> these blocks so that I could add to them but this is no longer
>>> allowed. However these blocks also cannot be resolved outside of the
>>> templates, so I cannot use "in" to reference them.
>>>
>>> It seems as if the "in" blocks are resolved before the "blockinherit"
>>> blocks are expanded.
>>>
>>> [1] https://src.fedoraproject.org/rpms/libsepol/c/c59879b8aa30ceb601ac4e449ee5e958c6659fbc?branch=rawhide

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift