wrong secmark labels for ipsec packets from local service

wrong secmark labels for ipsec packets from local service

[Christian Göttsche]

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

Re: wrong secmark labels for ipsec packets from local service

[Paul Moore]

On Thu, Feb 27, 2020 at 10:56 AM Christian Göttsche
<cgzones@googlemail.com> wrote:
> 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')?

Hello.

First off, it would help to see your netfilter configuration,
especially the secmark matching rules.

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?

-- 
paul moore
www.paul-moore.com

Re: wrong secmark labels for ipsec packets from local service

[Christian Göttsche]

Am Do., 27. Feb. 2020 um 20:45 Uhr schrieb Paul Moore <paul@paul-moore.com>:
>
> 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

Re: wrong secmark labels for ipsec packets from local service

[Paul Moore]

On Fri, Feb 28, 2020 at 9:37 AM Christian Göttsche
<cgzones@googlemail.com> wrote:
> Am Do., 27. Feb. 2020 um 20:45 Uhr schrieb Paul Moore <paul@paul-moore.com>:
> >
> > 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