On Fri, Feb 28, 2020 at 9:37 AM Christian Göttsche <cgzones@xxxxxxxxxxxxxx> wrote: > Am Do., 27. Feb. 2020 um 20:45 Uhr schrieb Paul Moore <paul@xxxxxxxxxxxxxx>: > > > > First off, it would help to see your netfilter configuration, > > especially the secmark matching rules. ... > The complete configuration is available at: > https://salsa.debian.org/cgzones-guest/misc-config/-/blob/master/nftables/nftables.conf Ah, nftables. Unfortunately I'm not very familiar with that syntax yet, so bear with me as I try to understand what is going on. > > As far as the source context for outbound packet:send traffic, for > > locally generated traffic this will always be the context associated > > with the sending socket. If dovecot is sending networking traffic > > using a socket it created, the source context for that traffic will be > > that of dovecot (unless dovecot has been augmented to set a different > > context on the socket). I may be misunderstanding your configuration, > > but dovecot is sending this traffic, yes? If not, who is sending this > > traffic? > > Dovecot is initiating the traffic, but dovecot sends on port > 993/imaps, and the packets I see are converted/translated/routed to > come from port 4500/ipsec-nat. > > Belonging to the packets are these logs: > > type=AVC msg=audit(1582898362.267:14845): avc: granted { forward_out > } for pid=0 comm="swapper/0" saddr=host_ip src=4500 > daddr=vpnclient_ip dest=53391 netif=eth0 > scontext=system_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:ipsecnat_server_packet_t:s0 tclass=packet Let's look at that AVC for a moment: * scontext is unlabeled_t, which is correct since you aren't using any type of labeled networking * tcontext is ipsecnat_server_packet_t which seems to be due to these sections of your nftables config (portions trimmed for clarity): secmark ipsecnat_server { "system_u:object_r:ipsecnat_server_packet_t:s0" } map secmapping_in { type inet_service : secmark elements = { ipsec-nat-t : "ipsecnat_server", } } chain input { type filter hook input priority -225; # get label for est/rel packets from connection ct state established,related meta secmark set ct secmark # label new incoming packets ct state new meta secmark set tcp dport map @secmapping_in ct state new meta secmark set udp dport map @secmapping_in # fix loopback labels iif lo meta secmark set tcp dport map @secmapping_in iif lo meta secmark set udp dport map @secmapping_in # save label onto connection ct state new ct secmark set meta secmark } chain output { type filter hook output priority 255; # get label for est/rel packets from connection ct state established,related meta secmark set ct secmark # fix loopback labels oif lo meta secmark set tcp sport map @secmapping_in oif lo meta secmark set udp sport map @secmapping_in # save label onto connection ct state new ct secmark set meta secmark } ... am I correct in that the config above is the only portion which is relevant to the secmark labeling we are talking about here? From what I can tell, the secmark is being set to ipsecnat_server_packet_t by this rule: oif lo meta secmark set udp sport map @secmapping_in ... as the source port is 4500 according to the AVC (I'm assuming UDP since it is NAT-T, but it doesn't really matter as TCP and UDP share the same mapping in your config). The only gotcha is that the AVC shows the netif as eth0 when the nft rule is for lo/loopback; the SELinux AVC we are seeing logs the outbound netif in the POSTROUTE hook *after* any IPsec processing, which might explain the "eth0". The only way I can explain the lo/loopback is if nftables is seeing that while the packet is undergoing the IPsec transforms; it has been too long since I've looked at that code (and it may have changed anyway, the network guys make changes like that often-ish). I'm also concerned about the packet:forward_out permission. In this case dovecot is a local process communicating with a remote IMAP server over the IPsec tunnel, correct? -- paul moore www.paul-moore.com
