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/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
