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 :)
accept4(2) isn't part of any standard (even though it'll be part in
the future) and raises warnings on some linux distro. Moreover, we
don't have thread that may fork at any time, so doing a mark_nonblock
after isn't a big deal.
this way, we can sandbox the listener with seccomp (todo) or capsicum
(already done) and still have CGI scripts. When we want to exec, we
tell the executor what to do, the executor executes the scripts and
send the fd backt to the listener.
Omar Polo