wrong secmark labels for ipsec packets from local service

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I am trying to confine network labeling via secmark and have an issue
regarding ipsec vpn packets.

Connections from clients are labeled correctly with
'ipsecnat_server_packet_t' and accessing external services (e.g.
google.com) over the vpn is working for clients.

What's causing problems is accessing local services, services running
on the same host as the vpn server.

When trying to access such, I am getting these packets and denials:

Dec 31 11:54:50 server kernel: nft_est IN= OUT=eth0 SRC=host_ip
DST=vpnclient_ip LEN=1476 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=4500 DPT=56602 LEN=1456
Dec 31 11:54:51 server kernel: nft_est IN= OUT=eth0 SRC=host_ip
DST=vpnclient_ip LEN=1476 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=4500 DPT=56602 LEN=1456
Dec 31 11:54:52 server audit[0]: AVC avc:  denied  { send } for  pid=0
comm="swapper/0" saddr=host_ip src=4500 daddr=vpnclient_ip dest=56602
netif=eth0 scontext=system_u:system_r:dovecot_t:s0
tcontext=system_u:object_r:ipsecnat_server_packet_t:s0 tclass=packet
permissive=0
Dec 31 11:54:54 server audit[9]: AVC avc:  denied  { send } for  pid=9
comm="ksoftirqd/0" saddr=host_ip src=4500 daddr=vpnclient_ip
dest=56602 netif=eth0 scontext=system_u:system_r:dovecot_t:s0
tcontext=system_u:object_r:ipsecnat_server_packet_t:s0 tclass=packet
permissive=0

The kernel processes a established response packet originating at port
4500 towards the vpn-client (so the packet label of
'ipsecnat_server_packet_t' is sensible), but the source context is
still the local service (dovecot with 'dovecot_t').
>From my point of view Dovecot should not be able to send packets
originating at port 4500 and I'd like not to allow the dovecot domain
(and other local service domain like webservers) to send packets
labeled 'ipsecnat_server_packet_t'.

Is there a possibility to change the source context of these packets
to the domain context of the vpn-server cause I do not see a
possibility to change the packet context to something permitted (like
'pop_server_packet_t')?

Best regards,
     Christian Göttsche


system information:
Linux desktopdebian 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13)
x86_64 GNU/Linux
nftables v0.9.3 (Topsy)
Linux strongSwan U5.8.2/K5.4.0-4-amd64




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux