* wrong secmark labels for ipsec packets from local service
@ 2020-02-27 15:56 Christian Göttsche
2020-02-27 19:45 ` Paul Moore
0 siblings, 1 reply; 4+ messages in thread
From: Christian Göttsche @ 2020-02-27 15:56 UTC (permalink / raw)
To: selinux
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: wrong secmark labels for ipsec packets from local service 2020-02-27 15:56 wrong secmark labels for ipsec packets from local service Christian Göttsche @ 2020-02-27 19:45 ` Paul Moore 2020-02-28 14:36 ` Christian Göttsche 0 siblings, 1 reply; 4+ messages in thread From: Paul Moore @ 2020-02-27 19:45 UTC (permalink / raw) To: Christian Göttsche; +Cc: selinux 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: wrong secmark labels for ipsec packets from local service 2020-02-27 19:45 ` Paul Moore @ 2020-02-28 14:36 ` Christian Göttsche 2020-02-28 17:18 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Christian Göttsche @ 2020-02-28 14:36 UTC (permalink / raw) To: Paul Moore; +Cc: selinux 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: wrong secmark labels for ipsec packets from local service 2020-02-28 14:36 ` Christian Göttsche @ 2020-02-28 17:18 ` Paul Moore 0 siblings, 0 replies; 4+ messages in thread From: Paul Moore @ 2020-02-28 17:18 UTC (permalink / raw) To: Christian Göttsche; +Cc: selinux 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-28 17:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-27 15:56 wrong secmark labels for ipsec packets from local service Christian Göttsche 2020-02-27 19:45 ` Paul Moore 2020-02-28 14:36 ` Christian Göttsche 2020-02-28 17:18 ` Paul Moore
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).