On 3.7.2020 16.49, Paul Moore wrote:
On Fri, Jul 3, 2020 at 6:28 AM Topi Miettinen <toiwoton@xxxxxxxxx> 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
