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): > * 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. Could that be handled by libseccomp provided some input from glibc (e.g., with some coordination, or glibc keeping the system calls it uses fixed across minor updates)? Otherwise the alternative is for programs not using seccomp and enabling all system calls to code handling untrusted input. regards, Nikos -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
