On 01/04/2017 04:44 AM, Kees Cook wrote:
On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore
<paul(a)paul-moore.com> wrote:
> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook <keescook(a)chromium.org> wrote:
>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore <paul(a)paul-moore.com> wrote:
>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook <keescook(a)chromium.org>
wrote:
>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore <paul(a)paul-moore.com>
wrote:
>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook
<keescook(a)chromium.org> 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