Re: [PATCH] network_support: Update LibreSwan configuration

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

 



On 6.9.2020 18.27, Richard Haines wrote:
Update ipsec.conf file that describes the labeled ipsec entries.

Signed-off-by: Richard Haines <richard_c_haines@xxxxxxxxxxxxxx>
---
This was used to test the updated LibreSwan that now supports
selinux_check_access(3) from https://github.com/libreswan/libreswan

  src/network_support.md | 38 ++++++++++++++++++++++++++++++++++++--
  1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/src/network_support.md b/src/network_support.md
index 36af1f4..4a3fd38 100644
--- a/src/network_support.md
+++ b/src/network_support.md
@@ -452,11 +452,45 @@ Context type identifier has never been defined in any standard. Pluto is
  configurable and defaults to '*32001*', this is the IPSEC Security
  Association Attribute identifier reserved for private use. Racoon is
  hard coded to a value of '*10*', therefore the pluto ***ipsec.conf**(5)*
-file must be configured as follows:
+configuration file *secctx-attr-type* entry must be set as shown in the
+following example:
```
  config setup
-        secctx-attr-type=10
+	protostack=netkey
+	plutodebug=all
+	logfile=/var/log/pluto/pluto.log
+	logappend=no
+	# A "secctx-attr-type" MUST be present:
+	secctx-attr-type=10
+	# Labeled IPSEC only supports the following values:
+	#   10 = ECN_TUNNEL - Used by racoon(8)
+	#   32001 = Default - Reserved for private use (see RFC 2407)
+	# These are the "IPSEC Security Association Attributes"
+
+conn selinux_labeled_ipsec_test
+	# ikev2 MUST be "no" as labeled ipsec is not yet supported by IKEV2
+	# There is a draft IKEV2 labeled ipsec document (July '20) at:
+	#   https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-03
+	ikev2=no
+	auto=start
+	rekey=no
+	authby=secret # set in '/etc/ipsec.secrets'
+	type=transport
+	left=192.168.1.198
+	right=192.168.1.148
+	ike=3des-sha1

Since this configuration may set an example for less experienced users who may just copy this without much understanding, would it be possible to use a more modern crypto algorithm? Also libreswan documentation tells that sha1 will be obsoleted in near future. Would something like "ike=aes_gcm256-sha2" work? I don't have a working libreswan setup.

https://libreswan.org/man/ipsec.conf.5.html

+	phase2=esp
+	phase2alg=3des-sha1

How about "phase2alg=aes_gcm256"?

-Topi



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

  Powered by Linux