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/