Re: wrong secmark labels for ipsec packets from local service

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

 



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.

table inet mysecmark {
secmark pop_client {
"system_u:object_r:pop_client_packet_t:s0"
}
secmark isakmp_server {
"system_u:object_r:isakmp_server_packet_t:s0"
}
secmark isakmp_client {
"system_u:object_r:isakmp_client_packet_t:s0"
}
secmark ipsecnat_server {
"system_u:object_r:ipsecnat_server_packet_t:s0"
}
secmark ipsecnat_client {
"system_u:object_r:ipsecnat_client_packet_t:s0"
}
secmark pop_server {
"system_u:object_r:pop_server_packet_t:s0"
}
map secmapping_in {
type inet_service : secmark
elements = {
isakmp : "isakmp_server",
ipsec-nat-t : "ipsecnat_server",
imaps : "pop_server",
}
}
map secmapping_out {
type inet_service : secmark
elements = {
imaps : "pop_client",
isakmp : "isakmp_client",
ipsec-nat-t : "ipsecnat_client",
}
}
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
iif lo meta secmark set tcp sport map @secmapping_out
iif lo meta secmark set udp sport map @secmapping_out
# 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
# label new outgoing packets
ct state new meta secmark set tcp dport map @secmapping_out
ct state new meta secmark set udp dport map @secmapping_out
# fix loopback labels
oif lo meta secmark set tcp dport map @secmapping_out
oif lo meta secmark set udp dport map @secmapping_out
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
}
}

The complete configuration is available at:
https://salsa.debian.org/cgzones-guest/misc-config/-/blob/master/nftables/nftables.conf


> 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



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

  Powered by Linux