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.)
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 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!
to connect to unix-domain sockets the `unix' pledge is needed and also
unveil "w". gmid can't mutate files because it doesn't pledge `wpath'
nor `cpath'.
The FreeBSD and Linux' sandbox can't deal with `fastcgi' and `proxy'
configuration rules: new sockets needs to be opened and it's either
impossible (the former) or a huge pain in the arse (the latter).
The sandbox is still always used in case only static files are served.
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.
be more strict and allow an openat only with the O_RDONLY flag. This
is kind of redundant with landlock, but still good to have. Landlock
is not yet widely available and won't kill the process upon policy
violation; furthermore, landlock can be disabled at boot time.
tested on GNU and musl libc on arch and alpine amd64.
Mickaël Salaün, the landlock author, pointed out the same error on the
got implementation. The assumption that not listed access
capabilities are implicitly denied is completely wrong:
> In a nutshell, the ruleset's handled_access_fs is required for
> backward and forward compatibility (i.e. the kernel and user space may
> not know each other's supported restrictions), hence the need to be
> explicit about the denied-by-default access rights.
It's been there for a long time, and it's frankly annoying to pretend
to use parameters. Most of the time, they're there to satisfy an
interface and nothings more.
refactor the landlock-related code into something more manageable.
The only real difference is that before the logger process would try
to landlock itself to "/" without perms, something that landlock
doesn't support (now it enables landlock and then restrict itself,
which is the correct move.)
Trying to implement some landlock policies (rules?) where possible.
The server process is, of course, the most dangerous process so start
with that.
The following should be equivalent to the unveil(2) call on OpenBSD:
allows only to read files and directories inside the vhost roots.
I'm assuming seccomp is enabled so I'm not trying to disallow actions
such as LANDLOCK_ACCESS_FS_EXECUTE or LANDLOCK_ACCESS_FS_REMOVE_FILE
which require syscalls that are already disallowed. I'm only trying
to limit the damage that the currently allowed system calls can do.
e.g. since write(2) is allowed, gmid could modify *any* file it has
access to; this is now forbidden by landlock.
There are still too many #ifdefs for my tastes, but it's still better
than the seccomp code.
Calling `configure' with --disable-sandbox will disable the sandbox
support *completely* at compile time. gmid will still complain at
compile time and during the startup.
Users shouldn't disable the sandbox if possible, but instead report
problem upstream so they get fixed (hopefully.)
#4 related
* SECCOMP_AUDIT_ARCH extended to support more architectures
* relax fcntl policy: allow the syscall regardless of the flags
* wrap every syscall in a ifdef, and add some (statx, fcntl64, ...)
used in x86
Some bits were taken from dhcpcd[0], thanks!
#4 related
[0]: https://roy.marples.name/git/dhcpcd/blob/HEAD:/src/privsep-linux.c
the logger process now can receive a file descriptor to write logs
to. At the moment the logic is simple, if it receives a file it logs
there, otherwise it logs to syslog. This will allow to log on custom
log files.
Not production-ready yet, but it's a start.
This adds a third ``backend'' for gmid: until now there it served
local files or CGI scripts, now FastCGI applications too.
FastCGI is meant to be an improvement over CGI: instead of exec'ing a
script for every request, it allows to open a single connection to an
``application'' and send the requests/receive the responses over that
socket using a simple binary protocol.
At the moment gmid supports three different methods of opening a
fastcgi connection:
- local unix sockets, with: fastcgi "/path/to/sock"
- network sockets, with: fastcgi tcp "host" [port]
port defaults to 9000 and can be either a string or a number
- subprocess, with: fastcgi spawn "/path/to/program"
the fastcgi protocol is done over the executed program stdin
of these, the last is only for testing and may be removed in the
future.
P.S.: the fastcgi rule is per-location of course :)
Omar Polo
Tobias Berger
Max