* Cil block inheritance
@ 2021-08-26 11:33 Vit Mojzis
2021-08-26 12:10 ` Dominick Grift
0 siblings, 1 reply; 7+ messages in thread
From: Vit Mojzis @ 2021-08-26 11:33 UTC (permalink / raw)
To: selinux; +Cc: Lukas Vrabec
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))
#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))
#semodule -i test.cil
#sesearch -A -s b.t
allow b.t b.t:file read;
Any pointers would be appreciated.
Thank you.
Vit
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cil block inheritance
2021-08-26 11:33 Cil block inheritance Vit Mojzis
@ 2021-08-26 12:10 ` Dominick Grift
2021-08-26 12:38 ` Vit Mojzis
0 siblings, 1 reply; 7+ messages in thread
From: Dominick Grift @ 2021-08-26 12:10 UTC (permalink / raw)
To: Vit Mojzis; +Cc: selinux, Lukas Vrabec
Vit Mojzis <vmojzis@redhat.com> 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
>
> #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
>
> #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@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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Cil block inheritance
2021-08-26 12:10 ` Dominick Grift
@ 2021-08-26 12:38 ` Vit Mojzis
2021-08-26 13:21 ` Dominick Grift
2021-08-26 13:46 ` Dominick Grift
0 siblings, 2 replies; 7+ messages in thread
From: Vit Mojzis @ 2021-08-26 12:38 UTC (permalink / raw)
To: Dominick Grift; +Cc: selinux, Lukas Vrabec
On 26. 08. 21 14:10, Dominick Grift wrote:
> Vit Mojzis <vmojzis@redhat.com> 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.
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
>>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Cil block inheritance
2021-08-26 12:38 ` Vit Mojzis
@ 2021-08-26 13:21 ` Dominick Grift
2021-08-26 14:46 ` Vit Mojzis
2021-08-26 19:25 ` James Carter
2021-08-26 13:46 ` Dominick Grift
1 sibling, 2 replies; 7+ messages in thread
From: Dominick Grift @ 2021-08-26 13:21 UTC (permalink / raw)
To: Vit Mojzis; +Cc: selinux, Lukas Vrabec
Vit Mojzis <vmojzis@redhat.com> writes:
> On 26. 08. 21 14:10, Dominick Grift wrote:
>> Vit Mojzis <vmojzis@redhat.com> 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))
This boils down to the same as above, yes.
>
> # 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.
Looks good enough to me (if it works then it works). I am just surprised that
the duplicate 'o' optional block is allowed.
Duplicate type declarations are no longer allowed as you noticed, but
fortunately you do not need them.
Whether this eventually is the best solution probably depends on other
aspects of the policy and on the requirements.
>
> 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@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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Cil block inheritance
2021-08-26 13:21 ` Dominick Grift
@ 2021-08-26 14:46 ` Vit Mojzis
2021-08-26 19:25 ` James Carter
1 sibling, 0 replies; 7+ messages in thread
From: Vit Mojzis @ 2021-08-26 14:46 UTC (permalink / raw)
To: Dominick Grift; +Cc: selinux, Lukas Vrabec
On 26. 08. 21 15:21, Dominick Grift wrote:
> Vit Mojzis <vmojzis@redhat.com> writes:
>
>> On 26. 08. 21 14:10, Dominick Grift wrote:
>>> Vit Mojzis <vmojzis@redhat.com> 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))
> This boils down to the same as above, yes.
>
>> # 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.
> Looks good enough to me (if it works then it works). I am just surprised that
> the duplicate 'o' optional block is allowed.
Thanks, I'll use different names for the optional blocks just to be sure.
>
> Duplicate type declarations are no longer allowed as you noticed, but
> fortunately you do not need them.
>
> Whether this eventually is the best solution probably depends on other
> aspects of the policy and on the requirements.
Sure, I guess I just needed to know that I'm not doing something wrong.
Thank you.
Vit
>
>> 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
>>>>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Cil block inheritance
2021-08-26 13:21 ` Dominick Grift
2021-08-26 14:46 ` Vit Mojzis
@ 2021-08-26 19:25 ` James Carter
1 sibling, 0 replies; 7+ messages in thread
From: James Carter @ 2021-08-26 19:25 UTC (permalink / raw)
To: Dominick Grift; +Cc: Vit Mojzis, SElinux list, Lukas Vrabec
On Thu, Aug 26, 2021 at 9:21 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Vit Mojzis <vmojzis@redhat.com> writes:
>
> > On 26. 08. 21 14:10, Dominick Grift wrote:
> >> Vit Mojzis <vmojzis@redhat.com> 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))
>
> This boils down to the same as above, yes.
>
> >
> > # 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.
>
> Looks good enough to me (if it works then it works). I am just surprised that
> the duplicate 'o' optional block is allowed.
>
Duplicate optional blocks are allowed unless an in-statement refers to
one of them, because that is the only time the name matters.
> Duplicate type declarations are no longer allowed as you noticed, but
> fortunately you do not need them.
>
Duplicate types are allowed when using secilc with the "-m" option.
Unfortunately, that doesn't help when using semodule. It would
probably be possible to add the option if necessary.
Jim
> Whether this eventually is the best solution probably depends on other
> aspects of the policy and on the requirements.
>
> >
> > 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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cil block inheritance
2021-08-26 12:38 ` Vit Mojzis
2021-08-26 13:21 ` Dominick Grift
@ 2021-08-26 13:46 ` Dominick Grift
1 sibling, 0 replies; 7+ messages in thread
From: Dominick Grift @ 2021-08-26 13:46 UTC (permalink / raw)
To: Vit Mojzis; +Cc: selinux, Lukas Vrabec
Vit Mojzis <vmojzis@redhat.com> writes:
> On 26. 08. 21 14:10, Dominick Grift wrote:
>> Vit Mojzis <vmojzis@redhat.com> 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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-08-26 19:17 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-26 11:33 Cil block inheritance Vit Mojzis
2021-08-26 12:10 ` Dominick Grift
2021-08-26 12:38 ` Vit Mojzis
2021-08-26 13:21 ` Dominick Grift
2021-08-26 14:46 ` Vit Mojzis
2021-08-26 19:25 ` James Carter
2021-08-26 13:46 ` Dominick Grift
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.