Roy Marples [Fri, 30 Oct 2020 14:19:16 +0000 (14:19 +0000)]
privsep: Allow logfile reopening in a chroot
Now that only the privileged actioneer does the actual logging
we can safely reopen the file we are logging to.
This also closes and re-opens the syslog connection.
Roy Marples [Fri, 30 Oct 2020 03:43:51 +0000 (03:43 +0000)]
privsep: Send all log messages to the privileged actioneer
If dhcpcd starts and no syslogd implementation is running then
various syscall filters could be triggered when dhcpcd wants to syslog
and it's already in a chroot.
Not all libc openlog implementations support LOG_NDELAY and
openlog does not return an error code and can also mask errno back to 0.
So we have no way of knowing if we have a syslog connection or not.
This means we cannot cache the connection at startup because syslog itself
will try and open if no connection.
As such, all logging is now directed to the dhcpcd privileged actioneer
process which will handle all the syslog and log file writing actions.
The only downside of this approach (other than an extra fd per process)
is that we no longer know which PID raised the message. While we could
put the correct PID in the logfile as we control the API, we cannot
put it into syslog as we cannot control that API.
As all privsep errors should log which function they came from this
will hopefully not be an issue as on the happy path only the master
process will log stuff.
Roy Marples [Thu, 15 Oct 2020 16:59:33 +0000 (17:59 +0100)]
privsep: Allow more syscalls through SECCOMP and add a debugger
This fixes PowerPC at least.
The debugger should not be enabled by default as the attacker
could keep the processes running.
However, it is need to work out which syscall is failing due to the
way SECCOMP works.
Roy Marples [Fri, 9 Oct 2020 19:21:52 +0000 (20:21 +0100)]
compat: Use libbsd's setproctitle(3)
Linux PRCTL variant, although more light weight, doesn't work on
some kernels.
This weighs in around 1k more, but always works.
It does play around with environ and args but unlike other
similar variants doesn't appear to stamp on what you actually
use in the program.
Roy Marples [Wed, 7 Oct 2020 13:11:47 +0000 (14:11 +0100)]
dhcpcd: Simplify the link handling even more
Move the IS_LINK_UP macro to if_is_link_up function to reduce
binary size.
Rather than DHCPCD_LINK option controlling the carrier state,
use it in if_is_link_up to determine the outcome.
Roy Marples [Mon, 28 Sep 2020 16:09:38 +0000 (17:09 +0100)]
BSD: struct if_data->ifi_link_state is the single source of truth
Vastly improve and simplify link detection on BSD.
dhcpcd either examines the whole system via getifaddrs(3) or
reacts to events via route(4).
In both cases we have struct if_data which has ifi_link_state.
Armed with this knowledge, we no longer need SIOCGIFDATA or
SIOCGIFMEDIA.
To solve the issue of newly attached interfaces having
LINK_STATE_UNKNOWN or some interfaces not even changing it,
we only change the local knowledge of interface flags when
reports them by getifaddrs(3) or route(4) when we change them.
For example, if we set IFF_UP and it succeeds we don't set this
internally until reported by the kernel as above.
This keeps flags and link state in sync with each other.
The hope is that the kernel can set the real link state before
it reports IFF_UP.
As such, we no longer require the poll option or need to enter a
tight loop for old interfaces.
Roy Marples [Thu, 24 Sep 2020 02:31:43 +0000 (03:31 +0100)]
BSD: NetBSD is the odd man out with SIOCGIFDATA
So setup the #defines like so.
On OpenBSD, pledge blocks it and there is no escape.
Luckily we already allow indirect ioctls via privsep so it works fine.
Roy Marples [Sat, 19 Sep 2020 13:40:50 +0000 (14:40 +0100)]
Linux: detect network namespace and deny udev in one
udev says whether an interface name is stable or not.
In a network namespace, udev claims the interface does not exist.
This makes sense because udev only operates in the root namespace.
Roy Marples [Sat, 12 Sep 2020 19:14:47 +0000 (20:14 +0100)]
dhcpcd: Only manipulate stdin, stdout and stderr when valid
UNIX application expect these to exist even if pointed at /dev/null.
We cannot change which fd they use, it's always 0, 1 and 2.
But if these fd's are not open when dhcpcd is called, they could
be assigned to dhcpcd internals.
In this instance we should not use the streams in anyway or form.