This PR should hopefully correct this.

admin@edge:~$ /usr/bin/vyos-hostsd-client --add-hosts --tag "DHCP-10.0.4.109" --host "HOST2,10.0.4.109"
Server returned an error: Could not connect to vyos-hostsd
admin@edge:~$ sudo /usr/bin/vyos-hostsd-client --add-hosts --tag "DHCP-10.0.4.109" --host "HOST2,10.0.4.109"
admin@edge:~$ cat /etc/hosts | grep 109
10.0.4.109	HOST2
admin@edge:~$ sudo /usr/bin/vyos-hostsd-client --delete-hosts  --tag "DHCP-10.0.4.109"
admin@edge:~$ cat /etc/hosts | grep 109

I tested the PR mentioned above and don't believe this will work. Reason is, is that https://github.com/vyos/vyos-1x/blob/current/src/systemd/isc-dhcp-server.service runs dhcpd as user: nobody and nobody is not in the sudo group, as far as i can tell. This is the error message im seeing.

May 19 21:37:45 vyos sudo[6141]:   nobody : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/vyos-hostsd-client

Yep. Confirmed, and that's the root issue here.

That also invalidates whatever this is trying to do:

https://github.com/vyos/vyos-1x/blob/7c55de11ca140fd8eed980c0c9db6302e1a05974/src/system/on-dhcp-event.sh#L66

PR416 should be the real fix here and PR413 should be reverted.

I'm not 100% sure of the full security implications of setting the socket permissions to 777.

The only other option might be to set the isc-dhcpd group to vyattacfg

We definitely shouldn't be setting permissions on the socket to 777 or 666 - whoever has write access to it can modify the DNS configuration (pdns-recursor) and can thus inject malicious DNS records or add himself as a DNS forwarder and do MITM attacks.

The option I see fit here is to:
a) add a vyos-hostsd user and group
b) set permissions on the socket to 'vyos-hostsd:vyos-hostsd 660' (or 770 if required)
c) add all users required to write to the socket to vyos-hostsd group with 'useradd $user vyos-hostsd'
d) run dhclient as its own user and not nobody (there's no limit to the number of users we can add, we can go wild here and run each thing that needs write access to the socket as its own user and add them all to the hostsd group - there can be no permissions between the different clients then as they can all be compartmentalized with their own user)
e) potentially even secure the socket and the daemon itself with selinux for more fine grained access control (for example radvd is run confined from the systemd service config)

In general it's never a good idea to set amything to other-writable. That's like accepting anyone can modify it, even unauthenticated users (if a vulnerability is found that can result in RCE though a service, that should be confined to itself and not have config access via other-writable/readable files)
In general I'd never set anything other-writable (and not readable if there is sensitive data in the file)

I'm sure there are other places in vyos that would need to be tightened up in security as well, but this is a start IMO.

Cant we run dhcpd as dhcp user which is also a member of hostsd group?

That’s how it is now and it doesn’t work.

I believe it’s because the dhcp server is set to run as a specific group, it doesn’t get to inherit its sub-group

@kroy Thanks for the fix! Is crux free from this problem?

@dmbaturin It should. It was vyos-hostsd and some of the rewrite to python that caused the issue initially.

crux still has enough of the old code so it doesn't have the issue.