this time targetting ABI level 3; partially based on how claudio@
handled it in rpki-client. Fun how this bit of code has come full
circle (gmid inspired what I wrote for got, which inspired what was
written for rpki-client, which has come back.)
gmid (like all other daemons that want to do privsep crypto) has a
very close relationship with libtls and need to stay in sync with
it.
OpenBSD' libtls was recently changed to use OpenSSL' EC_KEY_METHOD
instead of the older ECDSA_METHOD, on the gmid side we have to do
the same otherwise failures happens at runtime. In a similar manner,
privsep crypto is silently broken in the current libretls (next
version should fix it.)
The proper solution would be to complete the signer APIs so that
applications don't need to dive into the library' internals, but
that's a mid-term goal, for the immediate bundling the 'little'
libtls is the lesser evil.
The configure script has gained a new (undocumented for the time
being) flag `--with-libtls=bundled|system' to control which libtls
to use. It defaults to `bundled' except for OpenBSD where it uses
the `system' one. Note that OpenBSD versions before 7.3 (inclusive)
ought to use --with-libtls=bundled too since they still do ECDSA_METHOD.
Incorporate the OpenSMTPD' privsep crypto engine. The idea behind
it is to never load the certificate' private keys in a networked
process, instead they are loaded in a separate process (the `crypto'
one) which signs payloads on the behalf of the server processes.
This way, we greatly reduce the risk of leaking the certificate'
private key should the server process be compromised.
This currently compiles only on LibreSSL (portable fix is in the
way).
it's better than the previous Makefile.depend approach since this
automatically adapts to the included headers without requiring
manual intervention to regen the list.
It uses the 'common' proc.c from various OpenBSD-daemons.
gmid grew organically bit by bit and it was also the first place where I
tried to implement privsep. It wasn't done very well, in fact the
parent process (that retains root privileges) just fork()s a generation
of servers, all sharing *exactly* the same address space. No good!
Now, we fork() and re-exec() ourselves, so that each process has a fresh
address space.
Some features (require client ca for example) are temporarly disabled,
will be fixed in subsequent commits. The "ge" program is also
temporarly disabled as it needs tweaks to do privsep too.
it reached a point where this stuff is not maintenable. I'd like
to move forward with gmid, but the restriction of capsicum and the
linux environment at large that make landlock unusable (how can you
resolve DNS portably when under landlock?) -and don't get me started
on seccomp- makes it impossible for me to do any work.
So, I prefer removing the crap, resuming working on gmid by cleaning
stuff and consolidating the features, improving various things
etc... and then eventually see how to introduce some sandboxing
again on other systems. Patches to resume sandboxing are, as always,
welcome!
I really want to get rid of the `executor' process hack for CGI scripts
and its escalation to allow fastcgi and proxying to work on non-OpenBSD.
This drops the CGI support and the `executor' process entirely and is
the first step towards gmid 2.0. It also allows to have more secure
defaults.
On non-OpenBSD systems this means that the sandbox will be deactivated
as soon as fastcgi or proxying are used: you can't open sockets under
FreeBSD' capsicum(4) and I don't want to go thru the pain of making it
work under linux' seccomp/landlock. Patches are always welcome however.
For folks using CGI scripts (hey, I'm one of you!) not all hope is lost:
fcgiwrap or OpenBSD' slowcgi(8) are ways to run CGI scripts as they were
FastCGI applications.
fixes for the documentation and to the non-OpenBSD sandboxes will
follow.
Omar Polo
Anna “CyberTailor”