On Mon, Jan 18, 2016 at 3:51 AM, Florian Weimer <fweimer(a)redhat.com> 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):
* 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.
The sandstorm approach is striaghtforward: the disallowed things
return -ENOSYS. glibc can handle that quite nicely, as long as you
let existing stuff through.
--Andy