When doing DNSSEC lookups we need to know one or more DS or DNSKEY RRs
as trust anchors to validate lookups. With this change we add a
compiled-in trust anchor database, serving the root DS key as of today,
retrieved from:
https://data.iana.org/root-anchors/root-anchors.xml
The interface is kept generic, so that additional DS or DNSKEY RRs may
be served via the same interface, for example by provisioning them
locally in external files to support "islands" of security.
The trust anchor database becomes the fourth source of RRs we maintain,
besides, the network, the local cache, and the local zone.
Previously, we'd never do any single-label or root domain lookups via
DNS, thus leaving single-label lookups to LLMNR and the search path
logic in order that single-label names don't leak too easily onto the
internet. With this change we open things up a bit, and only prohibit
A/AAAA lookups of single-label/root domains, but allow all other
lookups. This should provide similar protection, but allow us to resolve
DNSKEY+DS RRs for the top-level and root domains.
(This also simplifies handling of the search domain detection, and gets
rid of dns_scope_has_search_domains() in favour of
dns_scope_get_search_domains()).
Sometimes when looking up entries in hashmaps indexed by a
DnsResourceKey it is helpful not having to allocate a full
DnsResourceKey dynamically just to use it as search key. Instead,
optionally allow allocation of a DnsResourceKey on the stack. Resource
keys allocated like that of course are subject to other lifetime cycles
than the usual Resource keys, hence initialize the reference counter to
to (unsigned) -1.
While we are at it, remove the prototype for
dns_resource_key_new_dname() which was never implemented.
Borked since
commit 3ee897d6c2
Author: Lennart Poettering <lennart@poettering.net>
Date: Wed Sep 23 01:00:04 2015 +0200
tree-wide: port more code to use send_one_fd() and receive_one_fd()
because here our fd is not connected and we need to specify
the address.
If we have a precisely matching NSEC RR for a name, we can use its type
bit field to synthesize NODATA cache lookup results for all types not
mentioned in there.
This is useful for mDNS where NSEC RRs are used to indicate missing RRs
for a specific type, but is beneficial in other cases too.
To test this, consider these two lines:
systemd-resolve-host -t NSEC nasa.gov
systemd-resolve-host -t SRV nasa.gov
The second line will not result in traffic as the first line already
cached the NSEC field.
This adds most basic operation for doing DNSSEC validation on the
client side. However, it does not actually add the verification logic to
the resolver. Specifically, this patch only includes:
- Verifying DNSKEY RRs against a DS RRs
- Verifying RRSets against a combination of RRSIG and DNSKEY RRs
- Matching up RRSIG RRs and DNSKEY RRs
- Matching up RR keys and RRSIG RRs
- Calculating the DNSSEC key tag from a DNSKEY RR
All currently used DNSSEC combinations of SHA and RSA are implemented. Support
for MD5 hashing and DSA or EC cyphers are not. MD5 and DSA are probably
obsolete, and shouldn't be added. EC should probably be added
eventually, if it actually is deployed on the Internet.
Now that we have dns_resource_record_to_wire_format() we can generate
the RR serialization we return to bus clients in ResolveRecord() with
it. We pass the RR data along in the original form, not the DNSSEC
canonical form, since that would mean we'd lose RR name casing, which is
however important to keep for DNS-SD services and similar.
This adds dns_resource_record_to_wire_format() that generates the raw
wire-format of a single DnsResourceRecord object, and caches it in the
object, optionally in DNSSEC canonical form. This call is used later to
generate the RR serialization of RRs to verify.
This adds four new fields to DnsResourceRecord objects:
- wire_format points to the buffer with the wire-format version of the
RR
- wire_format_size stores the size of that buffer
- wire_format_rdata_offset specifies the index into the buffer where the
RDATA of the RR begins (i.e. the size of the key part of the RR).
- wire_format_canonical is a boolean that stores whether the cached wire
format is in DNSSEC canonical form or not.
Note that this patch adds a mode where a DnsPacket is allocated on the
stack (instead of on the heap), so that it is cheaper to reuse the
DnsPacket object for generating this wire format. After all we reuse the
DnsPacket object for this, since it comes with all the dynamic memory
management, and serialization calls we need anyway.
When verifying signatures we need to be able to verify the original
data we got for an RR set, and that means we cannot simply drop flags
bits or consider RRs invalid too eagerly. Hence, instead of parsing the
DNSKEY flags store them as-is. Similar, accept the protocol field as it
is, and don't consider it a parsing error if it is not 3.
Of course, this means that the DNSKEY handling code later on needs to
check explicit for protocol != 3.
We need to check the same thing in multiple tests. Use a shared
macro to make it easier to update the list of errnos.
Change the errno code for "unitialized cgroup fs" for ENOMEDIUM.
Exec format error looks like something more serious.
This fixes test-execute invocation in mock.
Let's merge access_init() and mac_selinux_access_init(), and only call
mac_selinux_use() once, inside the merged function, instead of multiple
times, including in the caller.
See comments on:
https://github.com/systemd/systemd/pull/2053
Make sure dns_name_normalize(), dns_name_concat(), dns_name_is_valid()
do not accept/generate invalidly long hostnames, i.e. longer than 253
characters.
Labels of zero length are not OK, refuse them early on. The concept of a
"zero-length label" doesn't exist, a zero-length full domain name
however does (representing the root domain). See RFC 2181, Section 11.
When we have non-owner user or group entries, we need the mask
for the acl to be valid. But acl_calc_mask() calculates the mask
to include all permissions, even those that were masked before.
Apparently this happens when we inherit *:r-x permissions from
a parent directory — the kernel sets *:r-x, mask:r--, effectively
masking the executable bit. acl_calc_mask() would set the mask:r-x,
effectively enabling the bit. To avoid this, be more conservative when
to add the mask entry: first iterate over all entries, and do nothing
if a mask.
This returns the code closer to J.A.Steffens' original version
in v204-90-g23ad4dd884.
Should fix https://github.com/systemd/systemd/issues/1977.
For now, only add_acls_for_user is tested. When run under root, it
actually sets the acls. When run under non-root, it sets the acls for
the user, which does nothing, but at least calls the functions.
Most of the function is moved to acl-util.c to make it possible to
add tests in subsequent commit.
Setting of the mode in server_fix_perms is removed:
- we either just created the file ourselves, and the permission be better right,
- or the file was already there, and we should not modify the permissions.
server_fix_perms is renamed to server_fix_acls to better reflect new
meaning, and made static because it is only used in one file.
This renames __useless_struct_to_allow_trailing_semicolon__ everywhere
to _sd_useless_struct_to_allow_trailing_semicolon_, to follow our usual
rule of prefixing stuff from public headers that should be considered
internal with "_sd_".
While we are at it, also to be safe: when the struct is used in the C++
protector macros make sure to use two different names depending on
whether it appears in the C++ or C side of things. After all, there
might be compilers that don't consider C++ and C structs the same.
See https://github.com/systemd/systemd/pull/2052#discussion_r46067059
Let's distuingish the cases where our code takes an active role in
selinux management, or just passively reports whatever selinux
properties are set.
mac_selinux_have() now checks whether selinux is around for the passive
stuff, and mac_selinux_use() for the active stuff. The latter checks the
former, plus also checks UID == 0, under the assumption that only when
we run priviliged selinux management really makes sense.
Fixes: #1941
