4 ms·

For machines that never leave their normal network, changing it to reduce the risk of detection is one step in many compromises. We already use configuration m

by _jal 6y ago

For machines that never leave their normal network, changing it to reduce the risk of detection is one step in many compromises. We already use configuration management to do manage resolv.conf; any other method of modification is noncompliant. So this is just more at-best-wasteful cruft to strip out. More generally, why make this a daemon? There is zero reason for it to be resident other than on network changes. Should we have dedicated daemons for /etc/hosts, ldap.conf, and nsswitch.conf, too? How about inittab?

stonogo 6y ago
We already use configuration management to do manage resolv.conf; any other method of modification is noncompliant. So don't run resolvd. Problem solved forever. This exists as daemon because OpenBSD is in the process of rewriting certain parts of their code to have explicit privilege separation. They just committed another one to handle DHCP leases, for example.
- _jal 6y ago
  And I preemptively agreed with you: > cruft to strip out > rewriting certain parts of their code to have explicit privilege separation I was unaware that this was the goal. If it is, that's a better explanation for changing things than I've heard elsewhere. Still doesn't explain why it should be a daemon instead of a helper binary.
  - stonogo 6y ago
    It's a daemon so it can monitor the routing sockets for messages from dhcp/slaac/etc utilities that send updates. If it were a helper binary it would violate the privsep efforts.
rleigh 6y ago
For nsswitch, yes it should be a daemon. The current design maps in all sorts of unrelated (and potentially incompatible) junk into you process' address space. Far cleaner just to query over a socket. Doesn't need to be a system-wide daemon; it could just as easily be fired up on demand within a session (as in setsid) and shared between processes.

4 ms·

For machines that never leave their normal network, changing it to reduce the risk of detection is one step in many compromises. We already use configuration m

by _jal 6y ago

stonogo 6y ago
We already use configuration management to do manage resolv.conf; any other method of modification is noncompliant. So don't run resolvd. Problem solved forever. This exists as daemon because OpenBSD is in the process of rewriting certain parts of their code to have explicit privilege separation. They just committed another one to handle DHCP leases, for example.
- _jal 6y ago
  And I preemptively agreed with you: > cruft to strip out > rewriting certain parts of their code to have explicit privilege separation I was unaware that this was the goal. If it is, that's a better explanation for changing things than I've heard elsewhere. Still doesn't explain why it should be a daemon instead of a helper binary.
  - stonogo 6y ago
    It's a daemon so it can monitor the routing sockets for messages from dhcp/slaac/etc utilities that send updates. If it were a helper binary it would violate the privsep efforts.
rleigh 6y ago
For nsswitch, yes it should be a daemon. The current design maps in all sorts of unrelated (and potentially incompatible) junk into you process' address space. Far cleaner just to query over a socket. Doesn't need to be a system-wide daemon; it could just as easily be fired up on demand within a session (as in setsid) and shared between processes.