Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

On Mon, Jan 2, 2017 at 11:53 AM, Tyler Hicks <tyhicks(a)canonical.com&gt; wrote: I'm replying to this patchset posting because it his my inbox first, but my comments here apply to both this patchset and the other seccomp/audit patchset you posted. In my experience, we have two or three problems (the count varies depending on perspective) when it comes to seccomp filter reporting: 1. Inability to log all filter actions. 2. Inability to selectively enable filtering; e.g. devs want noisy logging, users want relative quiet. 3. Consistent behavior with audit enabled and disabled. My current thinking - forgive me, this has been kicking around in my head for the better part of six months (longer?) and I haven't attempted to code it up - is to create a sysctl knob for a system wide seccomp logging threshold that would be applied to the high 16-bits of *every* triggered action: if the action was at/below the threshold a record would be emitted, otherwise silence. This should resolve problems #1 and #2, and the code should be relatively straightforward and small. As part of the code above, I expect that all seccomp logging would get routed through a single logging function (sort of like a better implementation of the existing audit_seccomp()) that would check the threshold and trigger the logging if needed. This function could be augmented to check for CONFIG_AUDIT and in the case where audit was not built into the kernel, a simple printk could be used to log the seccomp event; solving problem #3. We could also add a SECCOMP_RET_AUDIT, or similar, if we still feel that is important (I personally waffle on this), but I think that is independent of the ideas above. Thoughts? -- paul moore www.paul-moore.com