Maximilian Bosch 6e87867ee3 nixos/postgresql: allow customisations of SystemCallFilter ...

Closes #385603

The problem described is that `wal-g` requires syscalls from `@resources`.
However, we don't have support for it in the module now and I don't
think it's reasonable to only support hardening adjustments for things
support by this module. Also, list is a bad datatype here since it
doesn't allow the level of customizations we need.

This is only for the syscall filterset since it's the option that's hard
to customize otherwise. For downstream configs, it's recommended to
adjust the hardening as needed in other cases.

Hence I decided to implement `services.postgresql.systemCallFilter` with
the following semantics:

* `systemCallFilter."~@resources" = true` adds `~@resources` to the
  filterset.

* Setting this to `false` (e.g. in a downstream configuration using
  `wal-g`) removes the entry `~@resources` from the filterset. In this
  case it's sufficient since `@system-service` implies `@resources` and
  the `~@resources` declaration after that discards that.

  I decided to not implement logic about negations in here, but to keep
  it rather simple by only allowing to set/unset entries.

As described in `systemd.exec(5)`, the ordering matters: e.g.
`@system-service` implies `@resources`, but `~@resources` _after_ that
reverts that. By default, the ordering of the keys is as follows:

* syscall groups (starting with `@`) come at first.
* negations of syscall groups (starting with `~@`) come after that.
* anything else at the end.

If further ordering is needed, it can be done like this:

```
{
  services.postgresql.systemCallFilter."~@resources" = {
    enable = true; # whether or not it's part of the final SystemCallFilter
    priority = 23; # ordering priority in the filterset.
  };
}
```

The lower the priority, the higher up the entry will be in the final
filterset.

2025-03-02 11:20:18 +01:00

32 KiB

Raw Blame History

View Raw