Re: libsepol regressions

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

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

> Fedora recently decided to pull in various libsepol patches from
> master[1]

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