Hello Kees, Will, In recent times I've been asked a couple of questions about seccomp(), and it seems like it would be worthwhile to include these topics in the seccomp(2) man page. Would you be able to help out with some answers?
=== Use of the instruction pointer in seccomp filters === The seccomp_data describing the system call includes the process's instruction pointer value. What use can be made of this information? My best guess is that you can use this information in conjunction with /proc/PID/maps to introspect the process layout and thus construct filters that conditionally operate based on which DSO is performing a system call. Is that a reasonable use case? Are there others? === Chained seccomp filters and SECCOMP_RET_KILL === The man page describes the behavior when multiple filter are installed If multiple filters exist, they are all executed, in reverse order of their addition to the filter tree (i.e., the most recently installed filter is executed first). The return value for the evaluation of a given system call is the first-seen SECCOMP_RET_ACTION value of highest precedence (along with its accompanying data) returned by execution of all of the filters. The question is: suppose one of the early filters returns SECCOMP_RET_KILL (which is the highest priority action), what is the purpose of executing the remaining filters. My best guess is that this about preventing the user from discovering which filter rule causes the sandboxed program to fail. Is this correct, or is there another reason? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/