On Mon, Jan 18, 2016 at 3:51 AM, Florian Weimer fweimer@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