On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
As Florian suggested it makes more sense to compartmentalize chrony so that only a small controlled part of it needs to run with seccomp. My recommendation, if you want to use libraries in the filtered code, make their authors aware of that, so that they document any changes in the used system calls, and if possible ask them to document the existing system calls used (e.g., similarly to: http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
Interesting. There is one huge caveat:
As well as an calls needed for memory allocation to work.
glibc malloc can basically call *anything*. We don't know what the future will bring. Currently, we use (off the top of my head, I haven't checked):
I appreciate what you are trying to do, but those seccomp filters totally break encapsulation. I have no idea how to support this properly, in a sustainable way. It appears very difficult to do this for independently evolving libraries
Well, ignoring the best sandboxing mechanism the linux kernel offers is not really a way forward. What would be the alternative? Would something like pledge [0,1] be more suitable more suitable to address your concerns?
regards, Nikos
[0]. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge .2?query=pledge [1]. https://outflux.net/blog/archives/2015/11/11/evolution-of-seccomp/