Re: Strange AVC denials without effect

[Topi Miettinen <toiwoton@gmail.com>]

On 3.7.2020 16.49, Paul Moore wrote:
> On Fri, Jul 3, 2020 at 6:28 AM Topi Miettinen <toiwoton@gmail.com> wrote:
>>
>> Hello,
>>
>> I renamed SELinux packet types and also without using type attributes
>> (like packet_type etc), so that refpolicy TE rules for packets should
>> not apply. Then I added new rules for the new types one by one as they
>> were needed. But there are lots of audit entries which would seem to
>> indicate that kernel_t is prevented from sending packets:
>>
>> type=AVC msg=audit(1593770235.180:3222): avc:  denied  { send } for
>> pid=408 comm="irq/30-iwlwifi" saddr=10.0.0.3 daddr=1.1.1.1 netif=wlan0
>> scontext=system_u:system_r:kernel_t:s0
>> tcontext=system_u:object_r:my_dns_client_packet_t:s0 tclass=packet
>> permissive=0
>>
>> In reality, the packets are sent. But kernel_t is not permissive and
>> there should not be any rules which would allow the action, so shouldn't
>> this prevent packet transmission?
> 
> Hmm, that is interesting.  Are you 100% certain that the packets which
> are the source of this AVC denial are the ones being sent over the
> wire(less)?
I don't know. The application sending the packets is very likely 
systemd-resolved. What could be the reason for packets originating from 
kernel_t instead of systemd_resolved_t?

 > Based on the permission, this is coming from the SELinux
> postroute hooks which simply return a DROP to the netfilter code, so
> if the packet is really getting sent it might be a case where the
> kernel is ignoring the netfilter hooks ... and that seems fairly
> unlikely to me.

Perhaps the check is fine but packet is incorrectly considered to be 
sent by the kernel (sk == NULL in security/selinux/hooks.c:5728)? Or 
perhaps it is, since the process is "irq/30-iwlwifi"?

> What kernel are you using?

Debian 5.7.0-1-amd64.

-Topi