resolved: don't attempt to send queries for DNSSEC RR types to servers not supporting them
If we already degraded the feature level below DO don't bother with sending requests for DS, DNSKEY, RRSIG, NSEC, NSEC3
or NSEC3PARAM RRs. After all, we cannot do DNSSEC validation then anyway, and we better not press a legacy server like
this with such modern concepts.
This also has the benefit that when we try to validate a response we received using DNSSEC, and we detect a limited
server support level while doing so, all further auxiliary DNSSEC queries will fail right-away.
resolved: when we get a packet failure from a server, don't downgrade UDP to TCP or vice versa
Under the assumption that packet failures (i.e. FORMERR, SERVFAIL, NOTIMP) are caused by packet contents, not used
transport, we shouldn't switch between UDP and TCP when we get them, but only downgrade the higher levels down to UDP.
resolved: properly handle UDP ICMP errors as lost packets
UDP ICMP errors are reported to us via recvmsg() when we read a reply. Handle this properly, and consider this a lost
packet, and retry the connection.
This also adds some additional logging for invalid incoming packets.
resolved: when we get a TCP connection failure, try again
Previously, when we couldn't connect to a DNS server via TCP we'd abort the whole transaction using a
"connection-failure" state. This change removes that, and counts failed connections as "lost packet" events, so that
we switch back to the UDP protocol again.
resolved: when DNS/TCP doesn't work, try DNS/UDP again
If we failed to contact a DNS server via TCP, bump of the feature level to UDP again. This way we'll switch back
between UDP and TCP if we fail to contact a host.
Generally, we prefer UDP over TCP, which is why UDP is a higher feature level. But some servers only support UDP but
not TCP hence when reaching the lowest feature level of TCP and want to downgrade from there, pick UDP again. We this
keep downgrading until we reach TCP and then we cycle through UDP and TCP.
Let's be a bit more precise with the editor configuration and specify a higher fill column of 119. This isn't as emacs'
default of 70, but also not particularly high on today's screens.
While we are at it, also set a couple of other emacs C coding style variables.
resolved: properly look for NSEC/NSEC3 RRs when getting a positive wildcard response
This implements RFC 5155, Section 8.8 and RFC 4035, Section 5.3.4:
When we receive a response with an RRset generated from a wildcard we
need to look for one NSEC/NSEC3 RR that proves that there's no explicit RR
around before we accept the wildcard RRset as response.
This patch does a couple of things: the validation calls will now
identify wildcard signatures for us, and let us know the RRSIG used (so
that the RRSIG's signer field let's us know what the wildcard was that
generate the entry). Moreover, when iterating trough the RRsets of a
response we now employ three phases instead of just two.
a) in the first phase we only look for DNSKEYs RRs
b) in the second phase we only look for NSEC RRs
c) in the third phase we look for all kinds of RRs
Phase a) is necessary, since DNSKEYs "unlock" more signatures for us,
hence we shouldn't assume a key is missing until all DNSKEY RRs have
been processed.
Phase b) is necessary since NSECs need to be validated before we can
validate wildcard RRs due to the logic explained above.
Phase c) validates everything else. This phase also handles RRsets that
cannot be fully validated and removes them or lets the transaction fail.
resolved: split up nsec3_hashed_domain() into two calls
There's now nsec3_hashed_domain_format() and nsec3_hashed_domain_make().
The former takes a hash value and formats it as domain, the latter takes
a domain name, hashes it and then invokes nsec3_hashed_domain_format().
This way we can reuse more code, as the formatting logic can be unified
between this call and another place.
resolved: when validating, first strip revoked trust anchor keys from validated keys list
When validating a transaction we initially collect DNSKEY, DS, SOA RRs
in the "validated_keys" list, that we need for the proofs. This includes
DNSKEY and DS data from our trust anchor database. Quite possibly we
learn that some of these DNSKEY/DS RRs have been revoked between the
time we request and collect those additional RRs and we begin the
validation step. In this case we need to make sure that the respective
DS/DNSKEY RRs are removed again from our list. This patch adds that, and
strips known revoked trust anchor RRs from the validated list before we
begin the actual validation proof, and each time we add more DNSKEY
material to it while we are doing the proof.
Instead of first iterating through all DNSKEYs in the DnsAnswer in
dns_transaction_check_revoked_trust_anchors(), and
then doing that a second time in dns_trust_anchor_check_revoked(), do so
only once in the former, and pass the dnskey we found directly to the
latter.
resolved: look for revoked trust anchors before validating a message
There's not reason to wait for checking for revoked trust anchors until
after validation, after all revoked DNSKEYs only need to be self-signed,
but not have a full trust chain.
This way, we can be sure that all trust anchor lookups we do during
validation already honour that some keys might have been revoked.
The domain name for this NSEC3 RR was originally stored in a variable
called "suffix", which was then renamed to "zone" in d1511b3338f431de3c95a50a9c1aca297e0c0734. Hence also rename the
RR variable accordingly.
Daniel Mack [Sun, 10 Jan 2016 17:11:22 +0000 (18:11 +0100)]
macro.h: provide a switch-case statement generator for IN_SET
Rather than walking a list of valid values one-by-one, generate a
switch-case statement for the IN_SET() macro. This allows the compiler to
further optimize its code output, possibly by generating jump tables.
This effectively decreases the binary size slightly.
The implementation is based on macro overloading depending on the number of
arguments. h/t to the following post:
Casey Schaufler [Fri, 8 Nov 2013 17:42:26 +0000 (09:42 -0800)]
smack: Handling network
- Set Smack ambient to match run label
- Set Smack netlabel host rules
Set Smack ambient to match run label
------------------------------------
Set the Smack networking ambient label to match the
run label of systemd. System services may expect to
communicate with external services over IP. Setting
the ambient label assigns that label to IP packets
that do not include CIPSO headers. This allows systemd
and the services it spawns access to unlabeled IP
packets, and hence external services.
A system may choose to restrict network access to
particular services later in the startup process.
This is easily done by resetting the ambient label
elsewhere.
Set Smack netlabel host rules
-----------------------------
If SMACK_RUN_LABEL is defined set all other hosts to be
single label hosts at the specified label. Set the loopback
address to be a CIPSO host.
If any netlabel host rules are defined in /etc/smack/netlabel.d
install them into the smackfs netlabel interface.
[Patrick Ohly: copied from https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commit;h=db4f6c9a074644aa2bf]
[Patrick Ohly: adapt to write_string_file() change in "fileio: consolidate write_string_file*()"]
[Patrick Ohly: create write_netlabel_rules() based on the original write_rules() that was removed in "smack: support smack access change-rule"]
[Patrick Ohly: adapted to upstream code review feedback: error logging, string constants]
Hui Wang [Wed, 6 Jan 2016 02:37:53 +0000 (10:37 +0800)]
keymap: remap microphone mute keycode for Lenovo Thinkcentre M800z
This Lenovo machine use codec Line2 to implement a microphone mute
button, it depends on the unsolicited interrupt to generate key event,
the scan code for this button is assigned to 0x00 in the linux kernel
driver, and the keycode is KEY_MICMUTE(248), we need to remap this
keycode to KEY_F20 to make this hotkey work in X11.
resolved: populate negative trust anchor by default
Let's increase compatibility with many private domains by default, and
ship a default NTA list of wel-known private domains, where it is
unlikely they will be deployed as official TLD anytime soon.
resolved: try to detect fritz.box-style private DNS zones, and downgrade to non-DNSSEC mode for them
This adds logic to detect cases like the Fritz!Box routers which serve
a private DNS domain "fritz.box" under the TLD "box" that does not
exist in the root servers. If this is detected DNSSEC validation is
turned off for this private domain, thus improving compatibility with
such private DNS zones.
This should be fairly secure as we first rely on the proof that .box
does not exist before this logic is applied. Nevertheless the logic is
only enabled for DNSSEC=allow-downgrade mode.
This logic does not work for routers that set up a full DNS zone directly
under a non-existing TLD, as in that case we cannot prove
that the domain is truly non-existing according to the root servers.
networkd previously knew an enum "ResolveSupport" for configuring
per-interface LLMNR support, resolved had a similar enum just called
"Support", with the same value and similar pasers.
Unify this, call the enum ResolveSupport, and port both daemons to it.
basic: add string table macros for "extended boolean" enums
In a couple of cases we maintain configuration settings that know an on
and off state, like a boolean, plus some additional states. We generally
parse them as booleans first, and if that fails check for specific
additional values.
This adds a generalized set of macros for parsing such settings, and
ports one use in resolved and another in networkd over to it.
tests: use sd_bus_flush_close_unref instead of sd_bus_unref in test-bus-cleanup
Fixes:
$ make valgrind-tests TESTS=test-bus-cleanup
==6363== 9 bytes in 1 blocks are possibly lost in loss record 1 of 28
==6363== at 0x4C2BBCF: malloc (vg_replace_malloc.c:299)
==6363== by 0x197D12: hexmem (hexdecoct.c:79)
==6363== by 0x183083: bus_socket_start_auth_client (bus-socket.c:639)
==6363== by 0x1832A0: bus_socket_start_auth (bus-socket.c:678)
==6363== by 0x183438: bus_socket_connect (bus-socket.c:705)
==6363== by 0x14B0F2: bus_start_address (sd-bus.c:1053)
==6363== by 0x14B592: sd_bus_start (sd-bus.c:1134)
==6363== by 0x14B95E: sd_bus_open_system (sd-bus.c:1235)
==6363== by 0x1127E2: test_bus_open (test-bus-cleanup.c:42)
==6363== by 0x112AAE: main (test-bus-cleanup.c:87)
==6363==
...
$ ./libtool --mode=execute valgrind ./test-bus-cleanup
==6584== LEAK SUMMARY:
...
==6584== possibly lost: 10,566 bytes in 27 blocks
Patrick Ohly [Mon, 21 Dec 2015 13:56:00 +0000 (14:56 +0100)]
mount-setup.c: fix handling of symlink Smack labelling in cgroup setup
The code introduced in f8c1a81c51 (= systemd 227) failed for me with:
Failed to copy smack label from net_cls to /sys/fs/cgroup/net_cls: No such file or directory
There is no need for a symlink in this case because source and target
are identical. The symlink() call is allowed to fail when the target
already exists. When that happens, copying the Smack label must be
skipped.
But the code also failed when there is a symlink, like "cpu ->
cpu,cpuacct", because mac_smack_copy() got called with
src="cpu,cpuacct" which fails to find the entry because the current
directory is not inside /sys/fs/cgroup. The absolute path to the existing
entry must be used instead.
resolved: when caching negative responses, honour NSEC/NSEC3 TTLs
When storing negative responses, clamp the SOA minimum TTL (as suggested
by RFC2308) to the TTL of the NSEC/NSEC3 RRs we used to prove
non-existance, if it there is any.
This is necessary since otherwise an attacker might put together a faked
negative response for one of our question including a high-ttl SOA RR
for any parent zone, and we'd use trust the TTL.
resolved: explicitly handle case when the trust anchor is empty
Since we honour RFC5011 revoked keys it might happen we end up with an
empty trust anchor, or one where there's no entry for the root left.
With this patch the logic is changed what to do in this case.
Before this patch we'd end up requesting the root DS, which returns with
NODATA but a signed NSEC we cannot verify, since the trust anchor is
empty after all. Thus we'd return a DNSSEC result of "missing-key", as
we lack a verified version of the key.
With this patch in place, look-ups for the root DS are explicitly
recognized, and not passed on to the DNS servers. Instead, if
downgrade-ok mode is on an unsigned NODATA response is synthesized, so
that the validator code continues under the assumption the root zone was
unsigned. If downgrade-ok mode is off a new transaction failure is
generated, that makes this case recognizable.
We already try hard not to create cyclic transaction dependencies, where
a transaction requires another one for DNSSEC validation purposes, which
in turn (possibly indirectly) pulls in the original transaction again,
thus resulting in a cyclic dependency and ultimately a deadlock since
each transaction waits for another one forever.
So far we wanted to avoid such cyclic dependencies by only going "up the
tree" when requesting auxiliary RRs and only going from one RR type to
another, but never back. However this turned out to be insufficient.
Consider a domain that publishes one or more DNSKEY but which has no DS
for it. A request for the domain's DNSKEY triggers a request for the
domain's DS, which will then fail, but return an NSEC, signed by the
DNSKEY. To validate that we'd request the DNSKEY again. Thus a DNSKEY
request results in a DS request which results in the original DNSKEY
request again. If the original lookup had been a DS lookup we'd end up
in the same cyclic dependency, hence we cannot statically break one of
them, since both requests are of course fully valid. Hence, do full
cyclic dependency checking: each time we are about to add a dependency
to a transaction, check if the transaction is already a dependency of
the dependency (recursively down the tree).
resolved: block transaction GC'ing while dns_transaction_request_dnssec_keys() is running
If any of the transactions started by
dns_transaction_request_dnssec_keys() finishes promptly without
requiring asynchronous operation this is reported back to the issuing
transaction from the same stackframe. This might ultimately result in
this transaction to be freed while we are still in its
_request_dnssec_keys() stack frame. To avoid memory corruption block the
transaction GC while in the call, and manually issue a GC after it
returned.
resolved: partially implement RFC5011 Trust Anchor support
With this patch resolved will properly handle revoked keys, but not
augment the locally configured trust anchor database with newly learned
keys.
Specifically, resolved now refuses validating RRsets with
revoked keys, and it will remove revoked keys from the configured trust
anchors (only until reboot).
This patch does not add logic for adding new keys to the set of trust
anchors. This is a deliberate decision as this only can work with
persistent disk storage, and would result in a different update logic
for stateful and stateless systems. Since we have to support stateless
systems anyway, and don't want to encourage two independent upgrade
paths we focus on upgrading the trust anchor database via the usual OS
upgrade logic.
Whenever a trust anchor entry is found revoked and removed from the
trust anchor a recognizable log message is written, encouraging the user
to update the trust anchor or update his operating system.
When applying canonical DNSSEC ordering for an RRset only order by the
wire format of the RRs' RDATA, not by the full wire formatting. The RFC
isn't particularly clear about this, but this is apparently how it is
done. This fixes validation of pentagon.gov's DS RRset.
projects / thirdparty / systemd.git / log
