security/vaultwarden: adding pledge(2) and unveil(2)
I inquired upstream (https://github.com/dani-garcia/vaultwarden/discussions/4033) if adding pledge(2) and unveil(2) into Vaultwarden would be accepted, and they replied that it would so long as it was "self-contained". I am currently running Vaultwarden with SQLite on OpenBSD 7.4-stable on the amd64 platform that has integrated pledge and unveil using the priv_sep crate (https://crates.io/crates/priv_sep) I maintain. Anyway, there is much work to do this properly so that it works on both amd64 and aarch64 for the many "knobs" that exist in the .env file. If anyone is interested in helping with this endeavor, I'd appreciate it. Conversely, if this is something that is not worth it or desired; then I'll stick to running a locally maintained version.
Re: dhcpcd consistently terminates
There are a few bugs in dhcpcd 9.4.1 as well as 10.0.1 that have since been resolved in the master branch. The bug that was causing dhcpcd to terminate every 5 days was related to how the privsep code responded to DHCP truncated packets: it would gracefully exit. This has been fixed with this commit: https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae Another bug that was fixed was the incorrect enforcement of the source UDP port from the DHCP server to be 67. This has been fixed with this commit: https://github.com/NetworkConfiguration/dhcpcd/commit/b9ac3021af19088fc70e0e7466adb717296cd3c7 The least important bug that was affecting me was privsep causing issues with dhcpcd -U . This has been fixed with this commit: https://github.com/NetworkConfiguration/dhcpcd/commit/41084f34629d4da5937dc44e0b68677b11eb65a3 I don't expect ports to be updated with this new version for OpenBSD 7.3. I am merely concluding the thread that I started.
Re: dhcpcd consistently terminates
On 5/21/23 02:27, Stuart Henderson wrote: Can you try the port diff below and confirm it's working for you please? I am already running master, and it works fine. I can try the port diff if you are willing to hold my hand. I have never done anything with ports. /usr/src is only 3 GiB in size too. I don't see a reason not to backport this if it works. I was under the impression that ports are almost always updated for snapshots only and not Release. Tangentially related to this. When I compiled the code, I received a few warnings; one of which Roy Marples said is due to an "OpenBSD header that needs fixing". This is the compilation warning that I get: if.c:909:30: warning: cast from 'char *' to 'struct cmsghdr *' increases required alignment from 1 to 4 [-Wcast-align] cm = (struct cmsghdr *)CMSG_NXTHDR(msg, cm)) ^~~~ /usr/include/sys/socket.h:537:6: note: expanded from macro 'CMSG_NXTHDR' (struct cmsghdr *)((char *)(cmsg) + _ALIGN((cmsg)->cmsg_len))) Do you know anything about that?
Re: dhcpcd consistently terminates
On 5/22/23 03:18, Stuart Henderson wrote: I don't have time to hand-hold at the moment. Perhaps someone else can, or see the ports faq for some details. Fair enough. I thought dealing with ports required -current as https://www.openbsd.org/faq/ports/testing.html states "The ports tree is developed against -current; there is no guarantee that new ports or updates will work correctly on the other branches. This means you should upgrade your system and ports tree to -current." Additionally, the diff you sent is based on -current. I'll look into it more. I noticed that some changes to the pf portion in README have been made, but it is still not quite correct. RFC 8415 does not state the source ports clients or servers MUST/SHOULD use; therefore the "from port <>" portions should be removed. Technically RFC 8415 does not require client-server communication to take place on a link-local address either, so you may want to remove that as well (emphasis added): "The client uses a link-local address _or addresses determined through other mechanisms_ for transmitting and receiving DHCP messages."
Re: dhcpcd consistently terminates
On 5/22/23 12:36, Stuart Henderson wrote:
Huh. So a client can use some other source port to send to the server,
but the server is still required to send packets back to port 546 on the
client rather than the source port the client actually used. Who came
up with this idea... (I am dubious that random DHCPv6 infrastructure on
the 'net will cope with a different source port either).
Anyway in that case the "out" rule would be
pass out quick on pppoe0 proto udp to port dhcpv6-server received-on none
The "in" rule is more problematic, I don't think we would want
pass in quick on pppoe0 proto udp to port dhcpv6-client
because that covers incoming packets to machines behind the router.
We can't use "self" because addresses are determined at PF ruleset load
time. Do we need "{(self) fe80::/10" or something?
Is this something you had to change yourself or is it just from a strict
reading of 8415?
RFC 2131 also does not state what source UDP ports DHCP clients and servers
MUST/SHOULD use. This caused Florian Obser to fix a bug in dhcpleased
(https://marc.info/?l=openbsd-bugs&m=163507791819694&w=2).
Shadrock Uhuru was having trouble with IPv6, and they got it to work once
they followed my pf ruleset
(https://marc.info/?l=openbsd-misc&m=167502694716840&w=2). I don't know
which rules exactly fixed their problem, but I don't think it makes sense
to have an overly restrictive ruleset. If one wants to iteratively add
more restrictive rules, then they can; but the base ruleset should conform
to RFC 8415.
I am aware that this allows more than one wants, but then again so does
not filtering for the exact IP of the DHCPv6 server. Obviously as the
maintainer, it is your call.
Re: dhcpcd consistently terminates
I believe a reasonable compromise is to allow any source UDP port and force the destination and source IP addresses to be link-local addresses. It is _very_ unlikely that a link-local address is not used by both server and client as it requires a previously agreed upon IP to be used which for most residential ISP customers is not going to happen: if you are already agreeing on some static IP address, then why not just use static IPs? This does violate RFC 8415, but it violates it in a lesser way than enforcing the UDP source port. I know that RFC 3203 allows DHCP servers to send uniform FORCERENEW packets, but I am not aware of such a mechanism for DHCPv6. If there is, then you certainly should not filter on IP address either. By forcing link-local addresses, I believe you will prevent forwarded packets too.
Re: dhcpcd consistently terminates
On 5/22/23 12:36, Stuart Henderson wrote: Or you can try this diff instead which applies to 7.3-stable. https://pbot.rmdir.de/TUCpK1TpCmhwZFuax3IBTA OK, I applied the diff and am currently running it. I successfully REBINDed the existing IPv6 and IPv4 leases. I can send an update once it successfully RENEWs the leases which should be in about a day.
Re: dhcpcd consistently terminates
The leases were successfully RENEWed.
dhcpcd consistently terminates
dhcpcd crashes every 5 days. I tried saving a crash report by setting sysctl.kern.nosuidcoredump=2; however dhcpcd.core was not written to /var/crash/dhcpcd. Here is some more information about my problem: https://marc.info/?l=openbsd-misc&m=167289142025844&w=2 Some other information not included in the above thread. According to dhcpcd.conf(5), there should be a file /var/db/dhcpcd/duid; however there is no such file nor has there ever been. It also states that the DHCPv6 client ID will be DUID+IAID; however they are the same according to dhcpcd -U em0: dhcp6_client_id=00041c021b030d04e70508065c0700080009 /var/log/daemon: dhcpcd[86796]: DUID 00:04:1c:02:1b:03:0d:04:e7:05:08:06:5c:07:00:08:00:09 The line in /etc/dhcpcd.conf that has always given me pause-since I haven't found examples on the Internet that use it-is the line: ia_pd 0/::/60. According to dhcpcd.conf(8), this should mean that a prefix should be delegated associated with the IAID 0 with prefix :: and prefix length of 60. Since there are no interfaces that follow, then dhcpcd should "assign a prefix to every other interface with a sla_id equivalent to the interface index assigned by the OS." However I explicitly deny all interfaces except em0-the interface requesting the prefix delegation-so this should mean that dhcpcd will assign a prefix to no other interface. I statically assign /64s from this /60 to my other interfaces. Perhaps dhcpcd requires assigning a prefix to at least one interface, but temporarily allows for it for like 5 days? Is there any use in building dhcpcd with debug symbols if dhcpcd.core is not being generated?
