On Mon, Jan 18, 2016 at 3:51 AM, Florian Weimer <fweimer@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
