On 01/04/2017 04:44 AM, Kees Cook wrote: > On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore wrote: >> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook wrote: >>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore wrote: >>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook wrote: >>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore wrote: >>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook wrote: >>>>>>> I still wonder, though, isn't there a way to use auditctl to get all >>>>>>> the seccomp messages you need? >>>>>> >>>>>> Not all of the seccomp actions are currently logged, that's one of the >>>>>> problems (and the biggest at the moment). >>>>> >>>>> Well... sort of. It all gets passed around, but the logic isn't very >>>>> obvious (or at least I always have to go look it up). >>>> >>>> Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at >>>> least one other action, but I can't remember which off the top of my >>>> head)? >>> >>> Sure, but if you're using audit, you don't need RET_ALLOW to be logged >>> because you'll get a full syscall log entry. Logging RET_ALLOW is >>> redundant and provides no new information, it seems to me. >> >> I only bring this up as it might be a way to help solve the >> SECCOMP_RET_AUDIT problem that Tyler mentioned. > > So, I guess I want to understand why something like this doesn't work, > with no changes at all to the kernel: > > Imaginary "seccomp-audit.c": > > ... > pid = fork(); > if (pid) { > char cmd[80]; > > sprintf(cmd, "auditctl -a always,exit -S all -F pid=%d", pid); > system(cmd); > release... > } else { > wait for release... > execv(argv[1], argv + 1); > } > ... > > This should dump all syscalls (both RET_ALLOW and RET_ERRNO), as well > as all seccomp actions of any kind. (Down side is the need for root to > launch auditctl...) Hey Kees - Thanks for the suggestion! Here are some of the reasons that it doesn't quite work: 1) We don't install/run auditd by default and would continue to prefer not to in some situations where resources are tight. 2) We block a relatively small number of syscalls as compared to what are allowed so auditing all syscalls is a really heavyweight solution. That could be fixed with a better -S argument, though. 3) We sometimes only block certain arguments for a given syscall and auditing all instances of the syscall could still be a heavyweight solution. 4) If the application spawns children processes, that rule doesn't audit their syscalls. That can be fixed with ppid=%d but then grandchildren pids are a problem. 5) Cleanup of the audit rule for an old pid, before the pid is reused, could be difficult. Tyler > > Perhaps an improvement to this could be enabling audit when seccomp > syscall is seen? I can't tell if auditctl already has something to do > this ("start auditing this process and all children when syscall X is > performed"). > > -Kees >