Allow rule not having any effect?!

Allow rule not having any effect?!

[Ian Pilcher]

I'm either missing something incredibly obvious, or something really,
really weird is going on.

I have a policy module that includes this rule.

   allow runcp_t etc_t:file { create write setattr };

And I can see that the rule is loaded.

   $ sesearch --allow -s runcp_t -t etc_t -c file -ds -dt
   allow runcp_t etc_t:file { create setattr write };

Nonetheless, I am still getting this denial.

   type=AVC msg=audit(1731345803.780:3765): avc:  denied  { create } for
   pid=289668 comm="cp" name="config"
   scontext=system_u:system_r:runcp_t:s0
   tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

AFAICT, this makes no sense at all.

Any ideas?

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================

Re: Allow rule not having any effect?!

[Dominick Grift]

Ian Pilcher <arequipeno@gmail.com> writes:

> I'm either missing something incredibly obvious, or something really,
> really weird is going on.
>
> I have a policy module that includes this rule.
>
>   allow runcp_t etc_t:file { create write setattr };
>
> And I can see that the rule is loaded.
>
>   $ sesearch --allow -s runcp_t -t etc_t -c file -ds -dt
>   allow runcp_t etc_t:file { create setattr write };
>
> Nonetheless, I am still getting this denial.
>
>   type=AVC msg=audit(1731345803.780:3765): avc:  denied  { create } for
>   pid=289668 comm="cp" name="config"
>   scontext=system_u:system_r:runcp_t:s0
>   tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

I suspect cp is called with -a when copying that "config" file.
It tries to create the file with an identity other than its own
(unconfined_u versus system_u) and object identity changes are
constrained by identity-based access control.

echo '(typeattributeset can_change_object_identity runcp_t)' >
mytest.cil && sudo semodule -i mytest.cil

The above should lift the object identity change constrain.

>
> AFAICT, this makes no sense at all.
>
> Any ideas?

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

SOLVED: Allow rule not having any effect?!

[Ian Pilcher]

Ran the AVC through audit2allow, just to see if it would give me any
clues, and sure enough, it actually did.  The problem was that the
SELinux users didn't match, i.e. system_u != unconfined_u.

Ironically, I actually hit this exact same problem 8 years ago.

https://selinux.tycho.nsa.narkive.com/lPRcuGbE/cannot-write-policy-to-allow-relabelto

On 11/11/24 11:30 AM, Ian Pilcher wrote:
> I'm either missing something incredibly obvious, or something really,
> really weird is going on.
> 
> I have a policy module that includes this rule.
> 
>    allow runcp_t etc_t:file { create write setattr };
> 
> And I can see that the rule is loaded.
> 
>    $ sesearch --allow -s runcp_t -t etc_t -c file -ds -dt
>    allow runcp_t etc_t:file { create setattr write };
> 
> Nonetheless, I am still getting this denial.
> 
>    type=AVC msg=audit(1731345803.780:3765): avc:  denied  { create } for
>    pid=289668 comm="cp" name="config"
>    scontext=system_u:system_r:runcp_t:s0
>    tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
> 
> AFAICT, this makes no sense at all.
> 
> Any ideas?
> 
-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================