Newer releases of systemd contain a change that removes not the part
after the first dot but the part after the last when determining the
interface name (apparently some interface names actually contain a dot).
This changes the default prefix to only contain one dot and avoids the
dots added by IPv4 addresses to create a unique interface/protocol for
each DNS server (it also replaces the `:` in IPv6 addresses with
something that might cause less conflicts).
References strongswan/strongswan#1353
When issuing a deregistration message, some last events may still be sent
by the daemon before deregistration completes. Ignore such event messages
silently during deregistration, avoiding exceptions like:
vici.exception.SessionException:
Unexpected response type 7, expected '5' (EVENT_CONFIRM)
The architecture of the Python client is completely blocking, which is fine
for many simple scripts. For more complex applications that do other I/O
and listen for vici events, the most feasible way to integrate the client is
to use a dedicated thread.
Unfortunately, Python has no simple support for thread cancellation. And
having that thread in a blocking recv() does not allow to terminate the
thread gracefully with an Event or the like.
As a way out, add a timeout to the listen() call, so the thread can
periodically do other things, like checking for termination Event and
react on it. Returning from listen() on timeout can be suboptimal, though,
as it involves registration/deregistration for events, including the risk
for missing events while not registered. So return a (None, None) tuple
instead on timeout, allowing the caller to periodically do other things
while staying registered for the events and continue in listen().
The timeout applies to the socket recv() for the start of the header, only,
so a message is either read in full or times out, avoiding the risk
of breaking message framing on the stream with partial reads.
Depending on the configured hard lifetime the default soft lifetime
might not make sense and could even cause rekeying to get disabled.
To avoid that, derive the soft lifetime from the hard lifetime so it's
10% higher than the soft lifetime.
References strongswan/strongswan#1414
Also avoid returning 0 and disabling rekeying in the rare case of
`jitter = rekey` and the `1/jitter` chance of that happening (returning
1 at least doesn't disable rekeying).
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#1414
This forces the use of a semicolon after INIT() and makes existing ones,
which was the case for basically all instances, necessary so e.g.
sonarcloud won't complain about an empty statement after every one of
them.
By evaluating to the allocated object, it would theoretically also allow
constructs like this:
struct_t *this;
return INIT(this,
.a = x,
.b = y,
);
or this:
array_insert(a, ARRAY_TAIL, INIT(this,
.a = x,
.b = y,
));
This makes sure the event is only triggered after the IKE_SA is fully
established and e.g. virtual IPs, additional peer addresses or
a modified reauth time (on the initiator) are assigned to it. This was
e.g. a problem for the selinux plugin if virtual IPs are used.
We use a separate task to trigger the event that's queued before the
child-create task so the event is triggered before the child_updown()
event. Same goes for the state change to IKE_ESTABLISHED.
A new condition is used to indicate the successful completion of all
authentication rounds, so we don't have to set the IKE_ESTABLISHED state
in the ike-auth task (it was used as condition in other tasks).
Since set_state() also sets the rekey and reauth times, this required
some minor changes in regards to how AUTH_LIFETIME notifies are handled.
Since e334bd46b1 ("ike-auth: Move packet collection to post_build()
method") tasks and plugins can modify the IKE_SA_INIT message independent
of the ike-auth task.
Otherwise, we can't open a dedicated IPv4 socket on the same port as the
IPv6 socket already is set up do receive IPv4 packets (unless we'd again
enable SO_REUSEADDR).
Fixes: 83da133712 ("socket-default: Don't set SO_REUSEADDR on IKE sockets anymore")
This was originally required when pluto and charon both bound sockets to
the same port to send messages. Pluto also received messages on them but
charon didn't and used a raw socket instead. Since the removal of pluto
we don't need to set this option anymore, which might actually mask
mistakes like running charon and charon-systemd concurrently (that could
result in messages getting sent fine by both daemons but only received
by one).
Note that a failure to create/bind the sockets will not immediately
result in a shutdown of the daemon. Instead, there will be an error
once the receiver tries to read any messages and also whenever the sender
attempts to send a request.
There are a lot of calls like this:
this->dispatcher->raise_event(this->dispatcher, "...", 0,
b->finalize(b));
However, if finalize() fails, e.g. because a previous call to add()
failed due to the size limit, it returns NULL. This then caused a
segmentation fault in raise_event() when it interacted with that value.
Closesstrongswan/strongswan#1278
Because flush() has to release the segment locks intermittently, threads
might add new entries (even with the change in the previous commit as the
IKE_SA might already be created, just not registered/checked in yet).
Since those entries are added to the front of the segment lists, the
enumerator in the previous step 2 didn't notice them and did not wait
for them to get checked in. However, step 3 and 4 then proceeded to
delete and destroy the entry and IKE_SA, which could lead to a crash
once the other thread attempts to check in the already destroyed IKE_SA.
This change combines the three loops of steps 2-4 but then loops over
the whole table until it's actually empty. This way we wait for and
destroy newly added entries.
Without ability to create SPIs, other threads are prevented from creating
new IKE_SAs while we are flushing existing IKE_SAs. However, there could
still be IKE_SAs already created that might get checked in while the
segments are temporarily unlocked to wait for threads to check existing
SAs in.
This is more consistent and e.g. allows to properly take into account
some settings that are also relevant during IKE_AUTH (e.g. childless).
We also already use the peer_cfg_t's ike_cfg_t when rekeying,
reauthenticating and reestablishing an IKE_SA (and e.g. for DSCP).
Also changed are some IKEv1 cases where get_ike_cfg() is called before
set_peer_cfg() without taking a reference to the ike_cfg_t that might
get replaced/destroyed (none of the cases were problematic, though, but
it also wasn't necessary to keep the ike_cfg_t around).
Closesstrongswan/strongswan#1238
When watching the output of `swanctl -l` during debugging, the debug
messages in query_sa/policy() cause a lot of noise in the logs (level 2
for DBG_KNL still has actually useful information that we want to see
in the logs) and they're not very useful.
Compared to the messages in the functions above, the ones in update_sa()
and get_replay_state() are not seen often. But since there already is a
log message on level 2 in update_sa(), they're kinda redundant.
Closesstrongswan/strongswan#1271
Normally, GCC sees that we terminate the destination with a zero byte.
However, when using `-fsanitize=address`, there seems to be additional
instrumentation code after strncpy() so GCC produces warnings like
these:
‘__builtin_strncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
When using the statement expression and a stack object along with
clang-11 and libasan, we get quite a lot of errors about reading
invalid memory. This is due to clang making the actual listener_t local
to the block, such that the access outside of the macros using
_assert_payload is (correctly) considered an error.
By using a heap allocated object, we can destroy it once the listener
returns FALSE (cleaning up properly), and since bus_t does not touch the
listener after that, we don't get any errors from libasan.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Since the allocated data was smaller than sizeof(eap_mschapv2_header_t),
the following compile error was triggered (with newer GCC versions):
eap_mschapv2.c: In function 'process_peer_success':
eap_mschapv2.c:945:12: error: array subscript 'eap_mschapv2_header_t[0]' is partly outside array bounds of 'unsigned char[6]' [-Werror=array-bounds]
945 | eap->code = EAP_RESPONSE;
| ^~
In file included from /usr/include/stdlib.h:587,
from ../../../../src/libstrongswan/utils/printf_hook/printf_hook.h:26,
from ../../../../src/libstrongswan/library.h:101,
from ../../../../src/libcharon/sa/eap/eap_method.h:28,
from eap_mschapv2.h:27,
from eap_mschapv2.c:18:
eap_mschapv2.c:944:15: note: object of size 6 allocated by '__builtin_alloca'
944 | eap = alloca(len);
| ^~~~~~
Closesstrongswan/strongswan#1188Closesstrongswan/strongswan#1215
The previous code did not ensure that there was a delay of at least
`try` seconds after each sent request. Instead, whenever the condvar was
signaled, which could be due to retransmitted responses or messages for
unrelated transactions (there could even be spurious wakeups), the counter
was increased and a retransmit sent. So instead of actually waiting for
15 seconds for a response (and sending 4 retransmits over that timespan),
it could happen that all five messages were sent within a second without
enough time to actually receive a response.
Using an absolute timeout that we reuse as long as there was no timeout
and the condvar was signaled for something unrelated, should ensure we
wait at least the intended delay after each sent message.
Closesstrongswan/strongswan#1154
This allows using the upper parts of the marks for other purposes. For
instance, with `mark_in=mark_out=%unique/0x0000ffff` mark values in the
upper two bytes would not get reset by the rules installed by this plugin.
However, note that in this example the daemon would have to get restarted
after 65'535 CHILD_SAs to reset the counter for unique marks, which is a
global 32-bit counter that's unaware of any masks.
Closesstrongswan/strongswan#1087
get_traffic_selectors() is called the same way also as responder when
selecting child configs via peer_cfg_t::select_child_cfg(). Replacing
TS for all child configs could lead to selecting one that later fails
to actually narrow the traffic selectors. Ignoring non-matching TS also
helps if we have a trap config with multiple remote subnets (otherwise,
we'd have to filter duplicates afterwards).
When installing traps, the hosts might be %any, in which case we allow
the configured (technically non-matching) TS for the wildcard use case.
Fixes: da82786b2d ("child-cfg: Always apply hosts to traffic selectors if proposing transport mode")
Closesstrongswan/strongswan#1143
This way we avoid having to pre-generate the message when it could
theoretically still get modified by a task that follows or from a plugin
via message() hook.
In particular as responder, this delays costly cryptographic operations
until the IKE_AUTH request is received, which is preferable to reduce
the impact of DoS attacks.
Another advantage is that the key material is not changed until all tasks
built or processed a message.
This way we avoid parsing messages with unexpected message IDs, which
might not even be possible if we don't have the keys anymore. However,
the next commit should avoid the latter and this way we avoid deriving
keys for retransmits or unexpected messages.
This also changes how retransmits for fragmented messages are triggered.
Previously, we waited for all fragments and reconstructed the message
before retransmitting the response. Now we only track the first
fragment and if we receive a retransmit of it respond immediately
without waiting for other fragments (which are now ignored). This is in
compliance with RFC 7383, section 2.6.1, and can avoid issues if there
are lots of fragments.