These won't be optimised away by the compiler and our arc4random
compat function should use them *if* available.
If none are then a warning will be emitted to say it's potentially insecure.
Hopefully only uclibc users will see this message.
Fixes#252.
* compat: Add OpenSSL libcrypto compatibility layer
Detect libcrypto in configure script. Only fall back
to using libcrypto when /usr libs are allowed and no
other compatible implementation is available or when
--with-openssl is passed explicitly.
Make sure libcrypto and libmd are never linked at the
same time.
Add OpenSSL based SHA256 and HMAC compat shims in
compat/crypt_openssl. Depeding on version and build flags,
libcrypto ships with a compatible SHA256 API in
"openssl/sha.h". OpenSSL 3 has deprecated the SHA API,
so if it is not detected we fall back to an EVP_DIGEST
based version.
Because the API might still be in use in OpenSSL internally,
the compatibility wrappers have a dhcpcd_ prefix to avoid
symbol conflicts.
* Add sha256 tests based on the existing hmac-md5 tests.
This allows a POSIX resource limited sandbox to be used at least
with privilege separation, which is better than just disabling
privilege separation entirely for when SECCOMP stops working due to
libc/kernel changes.
Even though we now have fully working kqueue(2) and epoll(7)
with our privsep code, ppoll(2) is faster and smaller for our
workload.
This time though, we will keep the code here as it's fully working
and while fixing kqueue we also fixed other bugs in dhcpcd as a result
so it's not time wasted at all.
kqueue allows for O(1) processing of active fd's an a more
robust signal handling method without the need to use global
variables to avoid calling functions during signal delivery.
The problems with the prior implemenation have now been fixed.
On FreeBSD udev, the function udev_device_new_from_subsystem_sysname
exists but is not implemented.
As such it breaks our device initialisation detection.
Disabled by default, but can be enabled with ./configure --with-udev
For systems without Capsicum or Pledge we can create a resource
limited sandbox provided that either ppoll(2) or works with
RLIMIT_NOFILES set to zero.
As far as dhcpcd is concerned, that means Linux and Solaris
won't work with this, but NetBSD and DragonFlyBSD will.
To achieve this, a special control proxy process will be spawned
just to accept new connections over the control socket because
this *cannot* be limited by RLIMIT_NOFILES.
epoll and kqueue are really too heavy weight.
With privsep, we now favour more processes for BPF and per address sockets.
As such, the number of fds to monitor will always be quite small.
All modern OS now have ppoll(2) (NetBSD has pollts, which is the same)
which works perfectly for us.
If neither are present, the a wrapper around pselect(2) is provided,
which can be found on all POSIX systems.
This makes the code a lot smaller and easier to follow.
The reduced binary size and memory usage is a nice win here.
All fd's in network facing processes are fully limited.
Capability mode is only enabled for BPF processes because
it's too restrictive otherwise - the reasons are noted
in the commit.
System users generally have _ preceeding their username.
Only use this user if it exists and their home dir is not /var/empty.
Otherwise default to using dhcpcd.
_dhcp home dir defaults to /var/empty.
System integrators can and should be in charge of changing it when needed.
Packagers on the other hand don't have such a luxury and so should not
use _dhcp by default.
As recent production kernels ship with ASLR by default which
stops dhcpcd running dead when this is enabled.
We dont want to break a systems boot, so force it via configure.
