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):
* sbrk
* mmap
* mprotect
* munmap
* mremap
* madvise
* futex
* open
* read
* close
(In some cases, there is some sort of fallback, or errors are ignored
and the optimization does not happen.)
Future versions might reasonably use:
* sched_getcpu
* clone
* clock_gettime
* more open/read/close
* readlink
* whatever system calls are used for memory protection keys
* whatever system calls are used for restartable sequences
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.
Florian