PostgreSQL considers seccomp() filters

Posted Oct 1, 2019 18:42 UTC (Tue) by kfox1111 (subscriber, #51633)
Parent article: PostgreSQL considers seccomp() filters

I think containers may be part of the solution.

The concern is postgres can be used with arbitrary dependencies and getting a perfect list of what all possible combinations of dependencies with postgres would be next to impossible. That I might agree with.

But, building a container, so that all its dependencies are fixed in stone, then running the test suite on it recording the syscalls would be much more reliable. The syscall list then would be static along with the static container.

PostgreSQL considers seccomp() filters

Posted Oct 1, 2019 19:56 UTC (Tue) by dezgeg (subscriber, #92243) [Link] (2 responses)

Never applying any updates sounds quite counterproductive from security point of view (which was the whole reason for the syscall filtering)...

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 0:31 UTC (Wed) by kfox1111 (subscriber, #51633) [Link] (1 responses)

Your assuming updates need to be applied from within, rather then from without.

You don't upgrade the contents of a container. You launch an upgraded container.

PostgreSQL considers seccomp() filters

Posted Oct 25, 2019 5:45 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]

This is generally a good idea - but I find the fixed-state model of containers, that works well for well-designed useful, but simple (in a good way) services inflicts a lot of pain when you apply it to a service whose main point is to manipulate complex state in complex ways.

PostgreSQL considers seccomp() filters

Posted Oct 1, 2019 21:29 UTC (Tue) by nix (subscriber, #2304) [Link]

running the test suite on it recording the syscalls would be much more reliable.

As was noted, the testsuite doesn't have anything like 100% coverage, particularly of error paths (not even SQLite's manages that, and it goes to incredible lengths to get closer than anyone else I've ever heard of) -- and even if it did, changes in the syscalls used by dependent libraries would break things anyway (this is not academic and has happened multiple times. Heck, it's happened multiple times to me alone, so I'm sure it's downright common for this to go wrong.)

Worse yet, PostgreSQL can execute arbitrary syscalls because it can invoke pluggable language interpreters and much else. I see no sane way to sandbox this without a major rearchitecture to move components seen as vulnerable into sandboxable subprocesses that do nothing else -- and even then you'd have the problem that any decent database server with server-side languages is supposed to execute more or less arbitrary code on behalf of users and is useless if it cannot. Diagnosing which arbitrary operations are suspicious and which are not seems a very difficult problem, and one almost certainly unimplementable under the constraints of seccomp sandboxes (which can look at args but cannot dereference pointers if an arg is a pointer, etc).

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 0:37 UTC (Wed) by KaiRo (subscriber, #1987) [Link] (2 responses)

Just that PostreSQL is not very suitable for containerization as there is no good upgrade path between major versions when you just switch containers and not have both an old and new binary installed in parallel on the same system with pg_upgrade having access to them both (which is almost impossible with containers). I hope this will be solved one day, as it will make pg containers a lot more attractive.

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 0:39 UTC (Wed) by cyphar (subscriber, #110703) [Link]

PostgreSQL is not really well-mapped to Docker-style application containers, but I run PostgreSQL inside an LXC/LXD container quite well (after all, it's tastes almost exactly like a VM).

PostgreSQL considers seccomp() filters

Posted Oct 2, 2019 8:45 UTC (Wed) by knan (subscriber, #3940) [Link]

The most promising route there is probably using replication from the still running old major version to the new in a new set of containers. Inconvenient but probably workable.