PostgreSQL considers seccomp() filters

A discussion on the pgsql-hackers mailing list at the end of August is another reminder that the suitability of seccomp() filters is likely more narrow than was hoped. Applying filters to the PostgreSQL database is difficult for a number of reasons and the benefit for the project and its users is not entirely clear. The discussion highlights the tradeoffs inherent in adding system-call filtering to a complex software suite; it may help crystallize the thinking of other projects that are also looking at supporting seccomp() filters.

Joe Conway raised the idea in an RFC patch posting. It added a way to filter system calls in the main postmaster process and, with a separate system-call list, in the per-session backends. It also showed how to generate the list of system calls that are being used by PostgreSQL under various workloads, such as the test targets in the Makefile or by running a specific application. Information on the system calls made is logged by the audit subsystem; those logs are then processed to produce the list. Once there is confidence that the list is complete—which may be a sticking point—the remaining system calls could be blocked so that executing them would cause an error.

But Peter Eisentraut was concerned that the list is going to be incomplete due to the "fantastic test coverage" needed to generate it and that it will require constant maintenance to keep up with GNU C Library (glibc) and other changes. Beyond that, PostgreSQL extensions will need their own lists of allowed system calls. Conway seems to see the support as something that those interested will maintain for themselves, rather than having a list that the project will distribute. "Perhaps most people never use this, but when needed (and increasingly will be required) it is available."

Tom Lane suggested that it made more sense to use some kind of static analysis to determine the system calls that PostgreSQL legitimately makes, rather than simply testing to produce the list. But he also doesn't quite see what threat model the feature is protecting against. Since it is PostgreSQL itself that is maintaining and configuring the system-call filter list, a compromise that allowed privileged code execution in PostgreSQL could just disable the filtering and restart PostgreSQL, making the filters moot:

Joshua Brindle thought that at least blacklisting some high-risk system calls would help bolster the security of a system running PostgreSQL. Systemd has some predefined lists that might be used as a starting point. He is also concerned that since the feature is just one component of a full solution, looking at it in isolation is not the right approach:

The fragility of seccomp() filters is also part of what concerned Andres Freund. He noted that there have already been PostgreSQL bug reports about seccomp() because of how it is used by some container-management systems. The system-call landscape is constantly shifting as well, he said, pointing to an LWN article about one seccomp()-related problem:

Lane wondered why SELinux was not being used; Brindle made it clear that while SELinux cannot be used to do system-call filtering, it is part of the overall PostgreSQL hardening effort. As an example of the kind of system call that could be blacklisted for PostgreSQL using seccomp(), Brindle pointed to madvise(), which he said is not preventable by SELinux, not used by PostgreSQL, and "a clear win in the dont-let-PG-be-a-vector-for-kernel-compromise arena".

But Freund cautioned that madvise() is used by glibc as part of its malloc() implementation. "That's *precisely* my problem with this approach." As Lane pointed out, calls that are buried deeply in dependencies of PostgreSQL are not going to be found easily via testing:

Yet another instance of seccomp() fragility was raised by Thomas Munro. The sync_file_range() system call on PowerPC and Arm has a sync_file_range2() variant with better argument ordering; glibc helpfully remaps calls to that variant on the relevant architectures. But Docker and other container managers did not include sync_file_range2() in their whitelists, leading to unexpected errors.

While generally acknowledging the problems mentioned, Brindle and Conway still think it makes sense to provide the hooks for the feature for those who want it. Brindle said:

But even for an optional feature, there is still a cost to PostgreSQL, Eisentraut said:

Conway noted that PostgreSQL is already being run under seccomp() filters, however. He and Brindle think that it would be better for the project to proactively implement support:

Conway wondered if just adding the hooks to load the filters would be a path forward, but Lane was not in favor of putting the filter controls inside the PostgreSQL process. That "seems like a fundamentally incorrect architecture", he said. In order to be a "credible security improvement", the filters need to be imposed on the PostgreSQL processes from the outside. As might be guessed, Brindle and Conway disagreed with that characterization. Their company (Crunchy Data) has customers that need the feature, so they will continue to pursue it, Conway said. For the PostgreSQL mainline, though, it would seem that the feature is not really welcome—at least in its present form.

While the appeal of filtering at the system-call level is strong, it is not entirely clear that it is the best way forward for everything. Processes like a browser's rendering engine, which was an initial seccomp() filtering target, are well suited to the approach. By their very nature, database engines—effectively general-purpose programming languages—do not really fit that mold. Adding system-call filters to something like Python (or Perl, Ruby, PHP, ...) is similarly problematic. Alternatives, at least for Linux, are not readily available, however, which may be causing people to try to fit round pegs in square holes.