Vit Mojzis <vmojzis@xxxxxxxxxx> writes: > On 26. 08. 21 14:10, Dominick Grift wrote: >> Vit Mojzis <vmojzis@xxxxxxxxxx> writes: >> >>> Hi, >>> recent changes in block inheritance broke our use case where we use >>> block inheritance for generating container policies >>> (https://github.com/containers/udica/tree/main/udica/templates). Basically >>> the policy is composed by inheriting selected "template" blocks, all >>> of which inherit "container" block, so that they can use types defined >>> there. >>> >>> Reproducer: >>> (block template1 (type t) ) >>> (block template2 (blockinherit template1)) >>> (block b (blockinherit template1) (blockinherit template2)) >> In this example there is no point in inheriting template1, because >> template2 already inherits it. >> >> (block template1 >> (type t)) >> (block template2 >> (blockinherit template1)) >> (block b (blockinherit template2) >> (allow t t (file (read)))) >> >> semodule -i test.cil >> seinfo -t b.t > Sure, but with more templates (as we have in udica) we get the same issue. > > (block template1 (type t) ) > (block template2 (blockinherit template1)) > (block template3 (blockinherit template1)) > (block b (blockinherit template2) (blockinherit template3)) > > # semodule -i test.cil > Re-declaration of type t > Previous declaration of type at /var/lib/selinux/targeted/tmp/modules/400/test/cil:1 > Failed to copy block contents into blockinherit > Failed to resolve AST > semodule: Failed! > > > Template2 and template3 mostly inherit template1 for the type defined > there (so that they can define rules containing the type). > >> >>> #semodule -i test.cil >>> Re-declaration of type t >>> Previous declaration of type at >>> /var/lib/selinux/targeted/tmp/modules/400/test/cil:1 >>> Failed to copy block contents into blockinherit >>> Failed to resolve AST >>> semodule: Failed! >>> >>> This used to work just fine. >>> >>> The following workaround seems to be working as intended, but I'm not >>> sure if it's the best approach. Types are only defined in template1 >>> and the rest contains "optional" block, so that I can use types >>> defined in template1). >>> >>> (block template1 (type t)) >>> (block template2 >>> (optional o >>> (allow t t ( file ( read ))) >>> ) >>> ) >>> (block b (blockinherit template1) (blockinherit template2)) >> You can just do something like this: >> >> (block template1 (type t)) >> (block template2 (blockinherit template1) (optional o (allow t t (file >> (read)))) >> (block b (blockinherit template2)) >> semodule -i test.cil >> sesearch -A -t b.t > With more templates, this break as well. > > But the following works: > > (block template1 (type t)) > (block template2 (optional o (allow t t (file (read))))) > (block template3 (optional o (allow t t (file (write))))) > (block b (blockinherit template1) (blockinherit template2) (blockinherit template3)) > > #semodule -i test.cil > #sesearch -A -s b.t > allow b.t b.t:file { read write }; > > Again, I'm not sure if this is the best solution, just the only one I managed to get working. Regardless, when push comes to shove compatiblity is probably just broken. People might have modules loaded that rely on this old behavior and upgrading SELinux user space could probably cause issues. > > Vit > >>> #semodule -i test.cil >>> #sesearch -A -s b.t >>> allow b.t b.t:file read; >>> >>> Any pointers would be appreciated. >>> >>> Thank you. >>> >>> Vit >>> > -- 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
