|
|
Subscribe / Log in / New account

PostgreSQL considers seccomp() filters

PostgreSQL considers seccomp() filters

Posted Oct 3, 2019 6:09 UTC (Thu) by cyphar (subscriber, #110703)
In reply to: PostgreSQL considers seccomp() filters by mjg59
Parent article: PostgreSQL considers seccomp() filters

I'll admit that I'm not convinced that pathname-as-a-string filtering is a good idea (though I'd love to know what usecases it would provide real protection in). Unless you restrict the set of syscalls the process can use to be incredibly small (i.e. only allowing open("/foo", O_RDWR) and no other filesystem-related syscalls), there are all sorts of ways you can get around pathname restrictions (symlink races, bind-mounts in mount namespaces, magic-links, and so on).

If the purpose would be stop malicious programs from doing something bad -- I think it would be more productive to just use mount namespaces and isolate away the rest of the filesystem entirely. Maybe you could make use of path-based filtering in combination with a read-only mount namespace, but I'm still not completely convinced.

If the purpose is to stop a trusted program from being tricked into operating on the wrong kinds of paths by an attacker, I think openat2 and the stuff I'm working on with libpathrs[1] (which takes advantage of existing tricks involving O_PATH and procfs) would be a better solution.

[1]: https://github.com/openSUSE/libpathrs


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds