dhcpcd-discuss

On 30/10/2020 07:19, shibe@xxxxxxx wrote:
> Thank you for your consideration.
>
> > I would hope that system packagers would test dhcpcd before blindly comitting it for their downstreams to use.
>
> One problem is that it can break not just on dhcpcd update, but also on changes in libc and kernel. Libc may use different syscalls depending on kernel version. Kernel can be decoupled from Linux distribution in case of containers. Also, users may want to opt for newer kernel for hardware support. It's understandable that distribution maintainers don't test every update on every possible combination of relevant software that users may have. And usually they don't have to, because APIs are backwards compatible. In this case, it's just the syscall filter that breaks compatibility.

Sadly this in indeed the case.
However, the view of glibc at least is that this is how it's supposed to work.

I'm just using the tools given.

> Now when breakage does get discovered during testing, the options are:
> delay update (of dhcpcd, libraries or kernel) until it's investigated and fixed upstream,
> develop a downstream patch,
> disable syscall filters in the build.
> I believe, there should be another option. If syscall whitelist was modifiable at runtime and the program reported blocked syscalls, it would be easier to fix, and it would be fixable by end-users and administrators who have a combination of software that was not explicitly tested.

dhcpcd really doesn't want report blocked syscalls by default. It wants to be 
killed by default. In a production environment, if there is an attack we want it 
dead incase of any other issues.

This makes it harder to debug because as other users have reported, sometimes 
the kernel just logs the fact that it was killed but not why.
If you have the technical knowledge to get this far and work out the syscall, 
then you also have the skills to communicate this upstream here and maybe even 
supply a patch.
If you don't have this knowledge then you won't be able to modify any user 
settable value anyway.

Looking at other applications which implement seccomp, they all take the same 
approach as dhcpcd and also note the same pitfall.
I will also note that this is no different from fixing user issues like "it 
doesn't work for me, please help!". It's just a lot more technical :)

systemd (from what I can tell) doesn't actually use seccomp itself, but allows a 
user setable seccomp per unit. IE, gives seccomp support to programs which lack it.

As it stands dhcpcd is currently the *only* DHCP or IPv4LL or DHCPv6 or RA 
client on Linux which supports seccomp. It was already the only one that 
supported privilege separation on Linux. These two feats make dhcpcd the most 
secure solution available today.

Roy