Dominick Grift <dominick.grift@xxxxxxxxxxx> writes: > Dominick Grift <dominick.grift@xxxxxxxxxxx> writes: > >> Dominick Grift <dominick.grift@xxxxxxxxxxx> 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@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
