Page MenuHomeVyOS Platform

DHCP isn't updating host file when hostfile-update enabled.
Closed, ResolvedPublicBUG

Description

In the configuration below /etc/hosts isn't getting updated with the host name from DHCP. I'd expect the host name from the lease to show up in /etc/hosts and be resolvable in DNS after enabling hostfile-update. Or I'm misunderstanding how this feature is supposed to be working. If this has been fixed in a newer release I'll try it to confirm.

service {
     dhcp-server {
         hostfile-update
         shared-network-name vm-network {
             authoritative
             subnet 10.0.3.0/24 {
                 default-router 10.0.3.1
                 dns-server 10.0.0.2
                 domain-name example.com
                 domain-search example.com
                 lease 86400
                 range vm-range {
                     start 10.0.3.200
                     stop 10.0.3.254
                 }
             }
         }
     }

vyos@fw1:~$ show dhcp server leases
IP address    Hardware address    State    Lease start          Lease expiration     Remaining    Pool        Hostname
------------  ------------------  -------  -------------------  -------------------  -----------  ----------  ----------
10.0.3.200    3e:1f:5d:b9:26:c0   active   2020/05/12 13:55:57  2020/05/13 13:55:57  18:27:29     vm-network  vm1
10.0.3.201    a6:3d:dc:16:fb:14   active   2020/05/12 15:17:16  2020/05/13 15:17:16  19:48:48     vm-network  shawns-vm

vyos@fw1:~$ cat /etc/hosts

### Autogenerated by VyOS ###
### Do not edit, your changes will get overwritten ###

# Local host
127.0.0.1       localhost
127.0.1.1       fw1.example.com fw1

# The following lines are desirable for IPv6 capable hosts
::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

# From DHCP and "system static host-mapping"
10.0.1.8	nas1.example.com # This is a static host-mapping and not in DHCP.

Details

Difficulty level
Unknown (require assessment)
Version
1.3-rolling-202005100117
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Revisions and Commits

Event Timeline

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
kroy changed the task status from Open to Needs testing.May 19 2020, 6:33 PM
kroy claimed this task.

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.

bash
May 19 21:37:45 vyos sudo[6141]:   nobody : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/vyos-hostsd-client
kroy changed the task status from Needs testing to Open.May 19 2020, 10:01 PM

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

kroy changed the task status from Open to Needs testing.May 20 2020, 1:46 AM

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.

kroy changed the task status from Needs testing to Confirmed.Sep 26 2020, 2:44 AM

@jjakob

This is a problem again.

The socket is owned by root:hostsd and permissions 770.

isc-dhcpd is in the hostsd group.

But when isc-dhcpd is started, it's started with the group nogroup. I don't think it gets to inherit its other groups when it runs like that.

The end result is that the dhcp server doesn't have permission to update vyos-hostsd

I can see two fixes:

  • Change socket to be owned by dhcpd:hostsd. I tried this on a test server and it seems to work. I don't know of the other implications of this
  • Change isc-dhcpd to run as the hostd group. This potentially seems like the better solution.

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 changed the task status from Confirmed to Needs testing.Nov 3 2020, 5:49 PM

This PR should fix this for now.

GitHub <noreply@github.com> closed this task as Resolved by committing Restricted Diffusion Commit.Nov 3 2020, 6:43 PM
GitHub <noreply@github.com> added a commit: Restricted Diffusion Commit.

@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.